[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] (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] [Commented] (DBCP-423) PoolingDataSource should implement Closeable
[
https://issues.apache.org/jira/browse/DBCP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 CloseablePoolingDataSource extends
> PoolingDataSource implements Closeable {
> public CloseablePoolingDataSource(ObjectPool pool) {
> super(pool);
> }
> @Override
> public void close() throws IOException {
> getPool().close();
> }
> }
--
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] [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] (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] [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(List list, Predicate > predicate) > Nice and simple, but doesn't allow extension; other ways of dealing with > predicate failure. > New factory method with enum: predicatedList(List list, Predicate 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(List 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(List list, Predicate > predicate) > Nice and simple, but doesn't allow extension; other ways of dealing with > predicate failure. > New factory method with enum: predicatedList(List list, Predicate 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(List 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(List list, Predicate > predicate) > Nice and simple, but doesn't allow extension; other ways of dealing with > predicate failure. > New factory method with enum: predicatedList(List list, Predicate 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(List 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(List list, Predicate > predicate) > Nice and simple, but doesn't allow extension; other ways of dealing with > predicate failure. > New factory method with enum: predicatedList(List list, Predicate 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(List 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] [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-tabpanel&focusedCommentId=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(List list, Predicate > predicate) > Nice and simple, but doesn't allow extension; other ways of dealing with > predicate failure. > New factory method with enum: predicatedList(List list, Predicate 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(List 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-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] [Updated] (CSV-147) Better error handling in CSV, see included code
[
https://issues.apache.org/jira/browse/CSV-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Peterson updated CSV-147:
Attachment: csv-exceptionsupport.patch
Please see attached patch containing a new test in CSVParserTest and a new
method for CSVParser that supports exception reporting and recovery.
> Better error handling in CSV, see included code
> ---
>
> Key: CSV-147
> URL: https://issues.apache.org/jira/browse/CSV-147
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.1
>Reporter: Steven Peterson
> Labels: easyfix
> Fix For: Discussion
>
> Attachments: csv-exceptionsupport.patch
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> When parsing long files, and there is problem with parsing the data, it would
> be very useful to know the exact data that is bad when an exception is
> thrown. As CSVParser maintains a portion of the current record that was read
> when an exception is thrown (in the 'record' property), can we make this
> information public through something like this:
> {code:java}
> public String[] getLastRecordData() {
> return this.record.toArray(new String[this.record.size()]);
> }
> {code}
> With a method like this, it would be easy to pull in part of the data that
> was in the faulty record after an exception was thrown, aiding in cleaning up
> the data.
--
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)
[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] [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)
