[jira] [Created] (MATH-1192) Descriptive statistics has a non-final protected field
Gilles created MATH-1192: Summary: Descriptive statistics has a non-final protected field Key: MATH-1192 URL: https://issues.apache.org/jira/browse/MATH-1192 Project: Commons Math Issue Type: Bug Affects Versions: 3.4 Reporter: Gilles Priority: Trivial Fix For: 4.0 Field windowSize should be private (there is setter method). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1193) Root-mean-square computation
Gilles created MATH-1193: Summary: Root-mean-square computation Key: MATH-1193 URL: https://issues.apache.org/jira/browse/MATH-1193 Project: Commons Math Issue Type: New Feature Reporter: Gilles Priority: Minor Fix For: 3.4.2 Add root-mean-square (a.k.a. quadratic mean) computation in * DescriptiveStatistics * SummaryStatistics -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-530) Rejecting items on predicate failure without throwing an Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277665#comment-14277665 ] Erik commented on COLLECTIONS-530: -- I created a suggested implementation. Not sure what the procedure is, but I will attach it to this issue, tell me what you think. Rejecting items on predicate failure without throwing an Exception -- Key: COLLECTIONS-530 URL: https://issues.apache.org/jira/browse/COLLECTIONS-530 Project: Commons Collections Issue Type: Improvement Components: List Affects Versions: 4.0 Reporter: Erik Fix For: 4.x The PredicatedList class doesn't allow entries that fail the predicate, but throws an Exception on entry. The problem I have with this, is that it places the onus of filtering out invalid entries on the caller. I typically add items in a loop. The item added is the result of a method call (which returns null if it can't create one). This problem is so common for me that I have created my own FilteredList class that simply ignores invalid entries. I would like the PredicatedList class to be capable of rejecting items without throwing an exception. I don't mind writing the code for this, but there are a great many ways in which this can be done. So I was wondering what the interface should look like. Separate FilteredList class. Works, but seems a little verbose for the purpose New factory method: filteredList(ListT list, Predicate? super T predicate) Nice and simple, but doesn't allow extension; other ways of dealing with predicate failure. New factory method with enum: predicatedList(ListT list, Predicate? super T predicate, PredicateFailEnum action) More verbose to use and adds an extra class, but allows more alternative ways to deal with predicate failure. One more nice thing is that it might be less confusing, because choosing between predicatedList and the above filteredList might not be so obvious. New factory method with interface: filteredList(ListT list, Predicate? super T predicate, PredicateFailInterface action) Complex, but the most flexible way of dealing with predicate failure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (COLLECTIONS-530) Rejecting items on predicate failure without throwing an Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik updated COLLECTIONS-530: - Comment: was deleted (was: first implementation suggestion) Rejecting items on predicate failure without throwing an Exception -- Key: COLLECTIONS-530 URL: https://issues.apache.org/jira/browse/COLLECTIONS-530 Project: Commons Collections Issue Type: Improvement Components: List Affects Versions: 4.0 Reporter: Erik Fix For: 4.x Attachments: COLLECTIONS-530-v0.0.1.alpha.zip The PredicatedList class doesn't allow entries that fail the predicate, but throws an Exception on entry. The problem I have with this, is that it places the onus of filtering out invalid entries on the caller. I typically add items in a loop. The item added is the result of a method call (which returns null if it can't create one). This problem is so common for me that I have created my own FilteredList class that simply ignores invalid entries. I would like the PredicatedList class to be capable of rejecting items without throwing an exception. I don't mind writing the code for this, but there are a great many ways in which this can be done. So I was wondering what the interface should look like. Separate FilteredList class. Works, but seems a little verbose for the purpose New factory method: filteredList(ListT list, Predicate? super T predicate) Nice and simple, but doesn't allow extension; other ways of dealing with predicate failure. New factory method with enum: predicatedList(ListT list, Predicate? super T predicate, PredicateFailEnum action) More verbose to use and adds an extra class, but allows more alternative ways to deal with predicate failure. One more nice thing is that it might be less confusing, because choosing between predicatedList and the above filteredList might not be so obvious. New factory method with interface: filteredList(ListT list, Predicate? super T predicate, PredicateFailInterface action) Complex, but the most flexible way of dealing with predicate failure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-530) Rejecting items on predicate failure without throwing an Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik updated COLLECTIONS-530: - Attachment: (was: COLLECTIONS-530-v0.0.1.alpha.zip) Rejecting items on predicate failure without throwing an Exception -- Key: COLLECTIONS-530 URL: https://issues.apache.org/jira/browse/COLLECTIONS-530 Project: Commons Collections Issue Type: Improvement Components: List Affects Versions: 4.0 Reporter: Erik Fix For: 4.x Attachments: COLLECTIONS-530-v0.0.1.alpha.zip The PredicatedList class doesn't allow entries that fail the predicate, but throws an Exception on entry. The problem I have with this, is that it places the onus of filtering out invalid entries on the caller. I typically add items in a loop. The item added is the result of a method call (which returns null if it can't create one). This problem is so common for me that I have created my own FilteredList class that simply ignores invalid entries. I would like the PredicatedList class to be capable of rejecting items without throwing an exception. I don't mind writing the code for this, but there are a great many ways in which this can be done. So I was wondering what the interface should look like. Separate FilteredList class. Works, but seems a little verbose for the purpose New factory method: filteredList(ListT list, Predicate? super T predicate) Nice and simple, but doesn't allow extension; other ways of dealing with predicate failure. New factory method with enum: predicatedList(ListT list, Predicate? super T predicate, PredicateFailEnum action) More verbose to use and adds an extra class, but allows more alternative ways to deal with predicate failure. One more nice thing is that it might be less confusing, because choosing between predicatedList and the above filteredList might not be so obvious. New factory method with interface: filteredList(ListT list, Predicate? super T predicate, PredicateFailInterface action) Complex, but the most flexible way of dealing with predicate failure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-530) Rejecting items on predicate failure without throwing an Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik updated COLLECTIONS-530: - Attachment: COLLECTIONS-530-v0.0.1.alpha.zip first implementation suggestion Rejecting items on predicate failure without throwing an Exception -- Key: COLLECTIONS-530 URL: https://issues.apache.org/jira/browse/COLLECTIONS-530 Project: Commons Collections Issue Type: Improvement Components: List Affects Versions: 4.0 Reporter: Erik Fix For: 4.x Attachments: COLLECTIONS-530-v0.0.1.alpha.zip The PredicatedList class doesn't allow entries that fail the predicate, but throws an Exception on entry. The problem I have with this, is that it places the onus of filtering out invalid entries on the caller. I typically add items in a loop. The item added is the result of a method call (which returns null if it can't create one). This problem is so common for me that I have created my own FilteredList class that simply ignores invalid entries. I would like the PredicatedList class to be capable of rejecting items without throwing an exception. I don't mind writing the code for this, but there are a great many ways in which this can be done. So I was wondering what the interface should look like. Separate FilteredList class. Works, but seems a little verbose for the purpose New factory method: filteredList(ListT list, Predicate? super T predicate) Nice and simple, but doesn't allow extension; other ways of dealing with predicate failure. New factory method with enum: predicatedList(ListT list, Predicate? super T predicate, PredicateFailEnum action) More verbose to use and adds an extra class, but allows more alternative ways to deal with predicate failure. One more nice thing is that it might be less confusing, because choosing between predicatedList and the above filteredList might not be so obvious. New factory method with interface: filteredList(ListT list, Predicate? super T predicate, PredicateFailInterface action) Complex, but the most flexible way of dealing with predicate failure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-530) Rejecting items on predicate failure without throwing an Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik updated COLLECTIONS-530: - Attachment: COLLECTIONS-530-v0.0.1.alpha.zip Rejecting items on predicate failure without throwing an Exception -- Key: COLLECTIONS-530 URL: https://issues.apache.org/jira/browse/COLLECTIONS-530 Project: Commons Collections Issue Type: Improvement Components: List Affects Versions: 4.0 Reporter: Erik Fix For: 4.x Attachments: COLLECTIONS-530-v0.0.1.alpha.zip The PredicatedList class doesn't allow entries that fail the predicate, but throws an Exception on entry. The problem I have with this, is that it places the onus of filtering out invalid entries on the caller. I typically add items in a loop. The item added is the result of a method call (which returns null if it can't create one). This problem is so common for me that I have created my own FilteredList class that simply ignores invalid entries. I would like the PredicatedList class to be capable of rejecting items without throwing an exception. I don't mind writing the code for this, but there are a great many ways in which this can be done. So I was wondering what the interface should look like. Separate FilteredList class. Works, but seems a little verbose for the purpose New factory method: filteredList(ListT list, Predicate? super T predicate) Nice and simple, but doesn't allow extension; other ways of dealing with predicate failure. New factory method with enum: predicatedList(ListT list, Predicate? super T predicate, PredicateFailEnum action) More verbose to use and adds an extra class, but allows more alternative ways to deal with predicate failure. One more nice thing is that it might be less confusing, because choosing between predicatedList and the above filteredList might not be so obvious. New factory method with interface: filteredList(ListT list, Predicate? super T predicate, PredicateFailInterface action) Complex, but the most flexible way of dealing with predicate failure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1195) Move the FastMathTestPerformance source
Gilles created MATH-1195: Summary: Move the FastMathTestPerformance source Key: MATH-1195 URL: https://issues.apache.org/jira/browse/MATH-1195 Project: Commons Math Issue Type: Sub-task Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 3.4.2 FastMathTestPerformance is stored in the test part of the repository but is not a test, it's a benchmark. Its code should be moved to the src/userguide part of the repository, where it can be updated to generate a report in a format suitable for publishing on the web site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBCP-423) PoolingDataSource should implement Closeable
[
https://issues.apache.org/jira/browse/DBCP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277809#comment-14277809
]
Thomas Neidhart commented on DBCP-423:
--
It is unfortunate that we can not touch the exception behavior but this should
be done in another major release imho.
On a second thought, the approach in BDS should be further improved as it now
catches a generic Exception and wraps it into a SQLException. If the pool will
throw an exception in its close method it will most likely be already a
SQLException (coming from the PoolableConnection implementation for example).
Thus we should not wrap a SQLException inside a SQLException but propagate the
SQLException. The same is already done in the PoolableConnection.close() method.
PoolingDataSource should implement Closeable
Key: DBCP-423
URL: https://issues.apache.org/jira/browse/DBCP-423
Project: Commons Dbcp
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Christian Schneider
Fix For: 2.1
Attachments: DBCP-423.patch
Currently PoolingDataSource only implements DataSource.
I have the following case in ops4j pax-jdbc. I offer a DataSourceFactory in
one bundle that can create a pooling DataSource.
Then in another bundle I create DataSources based on config in
ConfigurationAdmin. So when the config appears I create the DataSource, when
the config goes away I have to destroy it.
It is important to correctly dispose the DataSource as the pool has to be
closed. As I can not depend on dbcp in the bundle that destroys the
DataSource I currently have no simple way to destroy the DataSource.
This is where I create the DataSource:
https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool/src/main/java/org/ops4j/pax/jdbc/pool/impl/PooledDataSourceFactory.java
I was able to solve it by a kind of hack. I extended the PoolingDataSource
with a class that supports Closeable. So from the other bundle I could check
if the object implements Closeable and call close.
It would be a lot easier if PoolingDataSource would implement Closeable like
I did. The same is true for GenericObjectPool and the other pools. If they
would implement Closeable then handling them would be a lot easier.
They already support a close method so it would be a small change.
public class CloseablePoolingDataSourceC extends Connection extends
PoolingDataSourceC implements Closeable {
public CloseablePoolingDataSource(ObjectPoolC pool) {
super(pool);
}
@Override
public void close() throws IOException {
getPool().close();
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (VALIDATOR-356) IDN.toASCII drops trailing dot in Java 6 7
[
https://issues.apache.org/jira/browse/VALIDATOR-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated VALIDATOR-356:
---
Affects Version/s: 1.4.1 Release
IDN.toASCII drops trailing dot in Java 6 7
Key: VALIDATOR-356
URL: https://issues.apache.org/jira/browse/VALIDATOR-356
Project: Commons Validator
Issue Type: Bug
Affects Versions: 1.4.1 Release
Reporter: Sebb
Fix For: 1.5.0
The Java 6 method {{String java.net.IDN.toASCII(String)}} drops the final
input character if it is a dot (or equivalent, see RFC3490 3.1 1)
This causes problems for authority and domain validation.
This problem has been seen in
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
and
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
but appears to be fixed in
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Note also that the Java 8 version throws
java.lang.IllegalArgumentException: Empty label is not a legal name
if the argument contains two consecutive dots.
Fix to follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (VALIDATOR-356) IDN.toASCII drops trailing dot in Java 6 7
[
https://issues.apache.org/jira/browse/VALIDATOR-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved VALIDATOR-356.
Resolution: Fixed
Fix Version/s: 1.5.0
URL: http://svn.apache.org/r1651873
Log:
VALIDATOR-356 IDN.toASCII drops trailing dot in Java 6 7
Modified:
commons/proper/validator/trunk/src/changes/changes.xml
commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java
commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/DomainValidatorTest.java
commons/proper/validator/trunk/src/test/java/org/apache/commons/validator/routines/UrlValidatorTest.java
IDN.toASCII drops trailing dot in Java 6 7
Key: VALIDATOR-356
URL: https://issues.apache.org/jira/browse/VALIDATOR-356
Project: Commons Validator
Issue Type: Bug
Affects Versions: 1.4.1 Release
Reporter: Sebb
Fix For: 1.5.0
The Java 6 method {{String java.net.IDN.toASCII(String)}} drops the final
input character if it is a dot (or equivalent, see RFC3490 3.1 1)
This causes problems for authority and domain validation.
This problem has been seen in
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
and
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
but appears to be fixed in
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Note also that the Java 8 version throws
java.lang.IllegalArgumentException: Empty label is not a legal name
if the argument contains two consecutive dots.
Fix to follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MATH-1194) Create Commons Math Reports
Gilles created MATH-1194: Summary: Create Commons Math Reports Key: MATH-1194 URL: https://issues.apache.org/jira/browse/MATH-1194 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Minor The examples codes in src/userguide, in addition to illustrating how to use the CM library, could contain applications that create reports on various aspects of CM (e.g. benchmarks). The format of the generated output is yet TBD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VALIDATOR-356) IDN.toASCII drops trailing dot in Java 6 7
Sebb created VALIDATOR-356:
--
Summary: IDN.toASCII drops trailing dot in Java 6 7
Key: VALIDATOR-356
URL: https://issues.apache.org/jira/browse/VALIDATOR-356
Project: Commons Validator
Issue Type: Bug
Reporter: Sebb
The Java 6 method {{String java.net.IDN.toASCII(String)}} drops the final input
character if it is a dot (or equivalent, see RFC3490 3.1 1)
This causes problems for authority and domain validation.
This problem has been seen in
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
and
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
but appears to be fixed in
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Note also that the Java 8 version throws
java.lang.IllegalArgumentException: Empty label is not a legal name
if the argument contains two consecutive dots.
Fix to follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1081) DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check.
Jonathan Baker created LANG-1081: Summary: DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check. Key: LANG-1081 URL: https://issues.apache.org/jira/browse/LANG-1081 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Only testing == without testing equals() seems wrong. Should an equals() test be added after determining that the parameters are not arrays? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1082) Allow the objectsTriviallyEqual test to be disabled.
Jonathan Baker created LANG-1082: Summary: Allow the objectsTriviallyEqual test to be disabled. Key: LANG-1082 URL: https://issues.apache.org/jira/browse/LANG-1082 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial For example, a bean (e.g. a JPA record) has equals() overridden with a implementation that tests its id property. If two beans have the same ID, they correspond to the same record in the database. However, without tricking the objectsTriviallyEqual check in the DiffBuilder constructor, there is no way to build a DiffResult using before and after instances with changes to other properties (name, modification time, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1081) DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check.
[ https://issues.apache.org/jira/browse/LANG-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Baker updated LANG-1081: - Attachment: DiffBuilder-equals_test_in_append_Objects.patch DiffBuilderAppendsNonEqualObjectsFixed.java DiffBuilderAppendsNonEqualObjects.java Attached are examples of how to detect and correct the issue. DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check. - Key: LANG-1081 URL: https://issues.apache.org/jira/browse/LANG-1081 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Attachments: DiffBuilder-equals_test_in_append_Objects.patch, DiffBuilderAppendsNonEqualObjects.java, DiffBuilderAppendsNonEqualObjectsFixed.java Original Estimate: 1m Remaining Estimate: 1m Only testing == without testing equals() seems wrong. Should an equals() test be added after determining that the parameters are not arrays? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1082) Add option to disable the objectsTriviallyEqual test in DiffBuilder.
[ https://issues.apache.org/jira/browse/LANG-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Baker updated LANG-1082: - Summary: Add option to disable the objectsTriviallyEqual test in DiffBuilder. (was: Allow the objectsTriviallyEqual test to be disabled.) Add option to disable the objectsTriviallyEqual test in DiffBuilder. -- Key: LANG-1082 URL: https://issues.apache.org/jira/browse/LANG-1082 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Original Estimate: 0.25h Remaining Estimate: 0.25h For example, a bean (e.g. a JPA record) has equals() overridden with a implementation that tests its id property. If two beans have the same ID, they correspond to the same record in the database. However, without tricking the objectsTriviallyEqual check in the DiffBuilder constructor, there is no way to build a DiffResult using before and after instances with changes to other properties (name, modification time, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
