[jira] [Commented] (POOL-359) NullPointerException closing multiple GenericObjectPools
[
https://issues.apache.org/jira/browse/POOL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747334#comment-16747334
]
Michael Wintermeyer commented on POOL-359:
--
[~garydgregory], hope you enjoyed the holidays! Any chance it's possible to get
an update on when 2.6.1 might be released?
> NullPointerException closing multiple GenericObjectPools
>
>
> Key: POOL-359
> URL: https://issues.apache.org/jira/browse/POOL-359
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Michael Wintermeyer
>Priority: Major
> Fix For: 2.6.1
>
>
> {code:java}
> java.lang.NullPointerException
> at org.apache.commons.pool2.impl.EvictionTimer.cancel(EvictionTimer.java:97)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.startEvictor(BaseGenericObjectPool.java:753)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:694)
> {code}
> Possible when multiple pools in the same process each call #close.
> GenericObjectPool#close checks #isClosed before proceeding, but that call
> checks a non-static instance variable. It calls into EvictionTimer#cancel
> which sets the _static_ variable EvictionCache.executor to null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NUMBERS-90) DoublePrecisionContext
[
https://issues.apache.org/jira/browse/NUMBERS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen updated NUMBERS-90:
-
Description:
We should add a new class to commons-numbers-core that encapsulates
configurable strategies for comparing doubles. This is required for
GEOMETRY-11. Here is what I'm picturing:
{code:java}
// abstract class for the general concept of comparisons
public abstract class DoublePrecisionContext implements Comparator {
public abstract boolean equals(double a, double b);
public int compare(double a, double b) { /* ... */ }
public int compare(Double a, Double b) { /* ... */ }
}
// ...
// concrete class implementing a specific strategy
public class EpsilonUlpDoublePrecisionContext extends DoublePrecisionContext {
public EpsilonUlpDoublePrecisionContext(double eps, double maxUlps) { /*
... */ }
@Override
public boolean equals(double a, double b) { /* ... */ }
} {code}
Pull request: https://github.com/apache/commons-numbers/pull/28
was:
We should add a new class to commons-numbers-core that encapsulates
configurable strategies for comparing doubles. This is required for
GEOMETRY-11. Here is what I'm picturing:
{code:java}
// abstract class for the general concept of comparisons
public abstract class DoublePrecisionContext implements Comparator {
public abstract boolean equals(double a, double b);
public int compare(double a, double b) { /* ... */ }
public int compare(Double a, Double b) { /* ... */ }
}
// ...
// concrete class implementing a specific strategy
public class EpsilonUlpDoublePrecisionContext extends DoublePrecisionContext {
public EpsilonUlpDoublePrecisionContext(double eps, double maxUlps) { /*
... */ }
@Override
public boolean equals(double a, double b) { /* ... */ }
}
{code}
> DoublePrecisionContext
> --
>
> Key: NUMBERS-90
> URL: https://issues.apache.org/jira/browse/NUMBERS-90
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Blocker
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should add a new class to commons-numbers-core that encapsulates
> configurable strategies for comparing doubles. This is required for
> GEOMETRY-11. Here is what I'm picturing:
> {code:java}
> // abstract class for the general concept of comparisons
> public abstract class DoublePrecisionContext implements Comparator {
> public abstract boolean equals(double a, double b);
> public int compare(double a, double b) { /* ... */ }
> public int compare(Double a, Double b) { /* ... */ }
> }
> // ...
> // concrete class implementing a specific strategy
> public class EpsilonUlpDoublePrecisionContext extends DoublePrecisionContext {
> public EpsilonUlpDoublePrecisionContext(double eps, double maxUlps) { /*
> ... */ }
> @Override
> public boolean equals(double a, double b) { /* ... */ }
> } {code}
> Pull request: https://github.com/apache/commons-numbers/pull/28
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (NUMBERS-90) DoublePrecisionContext
[
https://issues.apache.org/jira/browse/NUMBERS-90?focusedWorklogId=187463=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-187463
]
ASF GitHub Bot logged work on NUMBERS-90:
-
Author: ASF GitHub Bot
Created on: 20/Jan/19 02:37
Start Date: 20/Jan/19 02:37
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #28: NUMBERS-90: adding
DoublePrecisionContext and FloatPrecisionContext
URL: https://github.com/apache/commons-numbers/pull/28#issuecomment-455832401
[](https://coveralls.io/builds/21170952)
Coverage increased (+0.2%) to 92.985% when pulling
**40eb7f5c0d5a5f8d027f6a0739e778e26007 on darkma773r:numbers-90** into
**2db8cdfdc65326a4a7e86c004c7c147a645944b0 on apache:master**.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 187463)
Time Spent: 20m (was: 10m)
> DoublePrecisionContext
> --
>
> Key: NUMBERS-90
> URL: https://issues.apache.org/jira/browse/NUMBERS-90
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Blocker
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should add a new class to commons-numbers-core that encapsulates
> configurable strategies for comparing doubles. This is required for
> GEOMETRY-11. Here is what I'm picturing:
> {code:java}
> // abstract class for the general concept of comparisons
> public abstract class DoublePrecisionContext implements Comparator {
> public abstract boolean equals(double a, double b);
> public int compare(double a, double b) { /* ... */ }
> public int compare(Double a, Double b) { /* ... */ }
> }
> // ...
> // concrete class implementing a specific strategy
> public class EpsilonUlpDoublePrecisionContext extends DoublePrecisionContext {
> public EpsilonUlpDoublePrecisionContext(double eps, double maxUlps) { /*
> ... */ }
> @Override
> public boolean equals(double a, double b) { /* ... */ }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (NUMBERS-90) DoublePrecisionContext
[
https://issues.apache.org/jira/browse/NUMBERS-90?focusedWorklogId=187462=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-187462
]
ASF GitHub Bot logged work on NUMBERS-90:
-
Author: ASF GitHub Bot
Created on: 20/Jan/19 02:31
Start Date: 20/Jan/19 02:31
Worklog Time Spent: 10m
Work Description: darkma773r commented on pull request #28: NUMBERS-90:
adding DoublePrecisionContext and FloatPrecisionContext
URL: https://github.com/apache/commons-numbers/pull/28
Adding DoublePrecisionContext and FloatPrecisionContext abstract classes
along with simple epsilon-based implementations. I also created a package named
"precision" for these and moved the "Precision" utility class there as well.
These changes are required for GEOMETRY-11.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 187462)
Time Spent: 10m
Remaining Estimate: 0h
> DoublePrecisionContext
> --
>
> Key: NUMBERS-90
> URL: https://issues.apache.org/jira/browse/NUMBERS-90
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should add a new class to commons-numbers-core that encapsulates
> configurable strategies for comparing doubles. This is required for
> GEOMETRY-11. Here is what I'm picturing:
> {code:java}
> // abstract class for the general concept of comparisons
> public abstract class DoublePrecisionContext implements Comparator {
> public abstract boolean equals(double a, double b);
> public int compare(double a, double b) { /* ... */ }
> public int compare(Double a, Double b) { /* ... */ }
> }
> // ...
> // concrete class implementing a specific strategy
> public class EpsilonUlpDoublePrecisionContext extends DoublePrecisionContext {
> public EpsilonUlpDoublePrecisionContext(double eps, double maxUlps) { /*
> ... */ }
> @Override
> public boolean equals(double a, double b) { /* ... */ }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (COLLECTIONS-709) MultiSet.Entry::getCount() isn't 0 after removing the last element
[
https://issues.apache.org/jira/browse/COLLECTIONS-709?focusedWorklogId=187450=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-187450
]
ASF GitHub Bot logged work on COLLECTIONS-709:
--
Author: ASF GitHub Bot
Created on: 19/Jan/19 23:40
Start Date: 19/Jan/19 23:40
Worklog Time Spent: 10m
Work Description: grimreaper commented on issue #66: COLLECTIONS-709 Set
Entry count to 0 after remove
URL:
https://github.com/apache/commons-collections/pull/66#issuecomment-455824429
This seems reasonable to me.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 187450)
Time Spent: 20m (was: 10m)
> MultiSet.Entry::getCount() isn't 0 after removing the last element
> --
>
> Key: COLLECTIONS-709
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-709
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1, 4.2
>Reporter: Robert Wertman
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Removing the final element(s) in a MultiSet doesn't set the count on a
> MultiSet.Entry to zero.
> {code:java}
> protected int getCountAfterRemoval(MultiSet multiset) {
> MultiSet.Entry entry = multiset.entrySet().iterator().next();
> entry.getCount(); // = 2
> multiset.remove(entry.getElement());
> entry.getCount(); // = 1
> multiset.remove(entry.getElement());
> return entry.getCount(); // Still = 1, should be 0
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-709) MultiSet.Entry::getCount() isn't 0 after removing the last element
[
https://issues.apache.org/jira/browse/COLLECTIONS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747298#comment-16747298
]
Robert Wertman commented on COLLECTIONS-709:
Pull request created with a fix:
https://github.com/apache/commons-collections/pull/66
> MultiSet.Entry::getCount() isn't 0 after removing the last element
> --
>
> Key: COLLECTIONS-709
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-709
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1, 4.2
>Reporter: Robert Wertman
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing the final element(s) in a MultiSet doesn't set the count on a
> MultiSet.Entry to zero.
> {code:java}
> protected int getCountAfterRemoval(MultiSet multiset) {
> MultiSet.Entry entry = multiset.entrySet().iterator().next();
> entry.getCount(); // = 2
> multiset.remove(entry.getElement());
> entry.getCount(); // = 1
> multiset.remove(entry.getElement());
> return entry.getCount(); // Still = 1, should be 0
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (COLLECTIONS-709) MultiSet.Entry::getCount() isn't 0 after removing the last element
[
https://issues.apache.org/jira/browse/COLLECTIONS-709?focusedWorklogId=187449=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-187449
]
ASF GitHub Bot logged work on COLLECTIONS-709:
--
Author: ASF GitHub Bot
Created on: 19/Jan/19 23:34
Start Date: 19/Jan/19 23:34
Worklog Time Spent: 10m
Work Description: CasualSuperman commented on pull request #66:
COLLECTIONS-709 Set Entry count to 0 after remove
URL: https://github.com/apache/commons-collections/pull/66
After removing the last element of a MultiSet, the Entry doesn't have a
count of 0. This makes the count accurate after removing the last item of a
MultiSet.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 187449)
Time Spent: 10m
Remaining Estimate: 0h
> MultiSet.Entry::getCount() isn't 0 after removing the last element
> --
>
> Key: COLLECTIONS-709
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-709
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1, 4.2
>Reporter: Robert Wertman
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing the final element(s) in a MultiSet doesn't set the count on a
> MultiSet.Entry to zero.
> {code:java}
> protected int getCountAfterRemoval(MultiSet multiset) {
> MultiSet.Entry entry = multiset.entrySet().iterator().next();
> entry.getCount(); // = 2
> multiset.remove(entry.getElement());
> entry.getCount(); // = 1
> multiset.remove(entry.getElement());
> return entry.getCount(); // Still = 1, should be 0
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COLLECTIONS-709) MultiSet.Entry::getCount() isn't 0 after removing the last element
Robert Wertman created COLLECTIONS-709:
--
Summary: MultiSet.Entry::getCount() isn't 0 after removing the
last element
Key: COLLECTIONS-709
URL: https://issues.apache.org/jira/browse/COLLECTIONS-709
Project: Commons Collections
Issue Type: Bug
Affects Versions: 4.2, 4.1
Reporter: Robert Wertman
Removing the final element(s) in a MultiSet doesn't set the count on a
MultiSet.Entry to zero.
{code:java}
protected int getCountAfterRemoval(MultiSet multiset) {
MultiSet.Entry entry = multiset.entrySet().iterator().next();
entry.getCount(); // = 2
multiset.remove(entry.getElement());
entry.getCount(); // = 1
multiset.remove(entry.getElement());
return entry.getCount(); // Still = 1, should be 0
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SANDBOX-508) OpenPGP - upgrade bouncycastle, junit and ant dependency
[ https://issues.apache.org/jira/browse/SANDBOX-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Beeker updated SANDBOX-508: --- Summary: OpenPGP - upgrade bouncycastle, junit and ant dependency (was: OpenPGP - upgrade bouncycastle) > OpenPGP - upgrade bouncycastle, junit and ant dependency > > > Key: SANDBOX-508 > URL: https://issues.apache.org/jira/browse/SANDBOX-508 > Project: Commons Sandbox > Issue Type: Improvement > Components: OpenPGP >Affects Versions: Nightly Builds >Reporter: Andreas Beeker >Priority: Major > Attachments: Upgrade_bouncycastle.patch > > > Upgrade bouncycastle dependency - see patch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SANDBOX-508) OpenPGP - upgrade bouncycastle, junit and ant dependency
[ https://issues.apache.org/jira/browse/SANDBOX-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Beeker updated SANDBOX-508: --- Description: Upgrade bouncycastle, junit and ant dependency - see patch (was: Upgrade bouncycastle dependency - see patch) > OpenPGP - upgrade bouncycastle, junit and ant dependency > > > Key: SANDBOX-508 > URL: https://issues.apache.org/jira/browse/SANDBOX-508 > Project: Commons Sandbox > Issue Type: Improvement > Components: OpenPGP >Affects Versions: Nightly Builds >Reporter: Andreas Beeker >Priority: Major > Attachments: Upgrade_bouncycastle.patch > > > Upgrade bouncycastle, junit and ant dependency - see patch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747120#comment-16747120
]
Otto Fowler commented on VFS-398:
-
[~b.eckenfels] please see the latest, i have tried to cut down on temp object
creation, and cached the schemes.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
