[jira] [Closed] (OGNL-258) StringConverter from 3.1.15 version (included in 2.5.13)
[ https://issues.apache.org/jira/browse/OGNL-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart closed OGNL-258. -- Resolution: Invalid Duplicates WW-4870 > StringConverter from 3.1.15 version (included in 2.5.13) > > > Key: OGNL-258 > URL: https://issues.apache.org/jira/browse/OGNL-258 > Project: Commons OGNL > Issue Type: Bug >Reporter: Amaury > > Hi Apache / Struts 2 team, > We've just discovered a bug with the new version 2.5.13 of Struts 2, mainly > in OGNL dependency. This is not the case with 2.5.10. > *Scenario*: we have a boolean method in a "if" condition statement in FTL > view. This method takes on argument which is a String ID in the format "X.Y" > (ex: "1.1). > *Result obtained during the OGNL parsing*: StringConverter is called > according to the "locale" of the browser and apparently with "fr_FR" locale, > the "X.Y" is converted to decimal format "X,Y" which is wrong since we want > to stick with our ID as it arrives. > It seems with en_US locale, the decimal conversion doesn't happen. > *Result expected*: the ID "X.Y" goes to the "if" statement as it is, not > converted in fr_Fr locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LANG-1358) Improve StringUtils#replace throughput
[ https://issues.apache.org/jira/browse/LANG-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved LANG-1358. - Resolution: Fixed Assignee: Pascal Schumacher Fix Version/s: 3.7 > Improve StringUtils#replace throughput > -- > > Key: LANG-1358 > URL: https://issues.apache.org/jira/browse/LANG-1358 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 3.6 >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher >Priority: Minor > Fix For: 3.7 > > > {quote} > StringUtils#replace uses substring to append a String region into a > StringBuilder. This causes useless copies, as StringBuilder#append can take > start and end indexes. > Modification: > Use proper StringBuilder#append overload > (https://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html#append-java.lang.CharSequence-int-int-). > Result: > Based on benchmark from JOOQ’s post > (https://blog.jooq.org/2017/10/11/benchmarking-jdk-string-replace-vs-apache-commons-stringutils-replace): > Benchmark Mode Cnt Score Error Units > StringReplaceBenchmark.testFastStringReplaceLongStringOneMatch thrpt 21 > 7546534,219 ± 145523,962 ops/s > StringReplaceBenchmark.testStringUtilsReplaceLongStringOneMatch thrpt > 21 7353512,552 ± 124498,228 ops/s > StringReplaceBenchmark.testFastStringReplaceLongStringSeveralMatches > thrpt 21 5077255,810 ± 62358,937 ops/s > StringReplaceBenchmark.testStringUtilsReplaceLongStringSeveralMatches > thrpt 21 4108357,612 ± 92909,038 ops/s > StringReplaceBenchmark.testFastStringReplaceShortStringOneMatch thrpt > 21 15911221,949 ± 541064,693 ops/s > StringReplaceBenchmark.testStringUtilsReplaceShortStringOneMatch thrpt > 21 10677897,475 ± 491091,973 ops/s > StringReplaceBenchmark.testFastStringReplaceShortStringSeveralMatches > thrpt 21 9271742,251 ± 220150,121 ops/s > StringReplaceBenchmark.testStringUtilsReplaceShortStringSeveralMatches > thrpt 21 6158829,188 ± 99637,607 ops/s > {quote} > source: https://github.com/apache/commons-lang/pull/300 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang issue #300: Improve StringUtils#replace throughput
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/300 Thanks! ð ---
[GitHub] commons-lang pull request #300: Improve StringUtils#replace throughput
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/300 ---
[jira] [Created] (LANG-1358) Improve StringUtils#replace throughput
Pascal Schumacher created LANG-1358: --- Summary: Improve StringUtils#replace throughput Key: LANG-1358 URL: https://issues.apache.org/jira/browse/LANG-1358 Project: Commons Lang Issue Type: Improvement Affects Versions: 3.6 Reporter: Pascal Schumacher Priority: Minor {quote} StringUtils#replace uses substring to append a String region into a StringBuilder. This causes useless copies, as StringBuilder#append can take start and end indexes. Modification: Use proper StringBuilder#append overload (https://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html#append-java.lang.CharSequence-int-int-). Result: Based on benchmark from JOOQ’s post (https://blog.jooq.org/2017/10/11/benchmarking-jdk-string-replace-vs-apache-commons-stringutils-replace): Benchmark Mode Cnt Score Error Units StringReplaceBenchmark.testFastStringReplaceLongStringOneMatch thrpt 21 7546534,219 ± 145523,962 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringOneMatch thrpt 21 7353512,552 ± 124498,228 ops/s StringReplaceBenchmark.testFastStringReplaceLongStringSeveralMatches thrpt 21 5077255,810 ± 62358,937 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringSeveralMatches thrpt 21 4108357,612 ± 92909,038 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringOneMatch thrpt 21 15911221,949 ± 541064,693 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringOneMatch thrpt 21 10677897,475 ± 491091,973 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringSeveralMatches thrpt 21 9271742,251 ± 220150,121 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringSeveralMatches thrpt 21 6158829,188 ± 99637,607 ops/s {quote} source: https://github.com/apache/commons-lang/pull/300 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LANG-1358) Improve StringUtils#replace throughput
[ https://issues.apache.org/jira/browse/LANG-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-1358: Description: {quote} StringUtils#replace uses substring to append a String region into a StringBuilder. This causes useless copies, as StringBuilder#append can take start and end indexes. Modification: Use proper StringBuilder#append overload (https://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html#append-java.lang.CharSequence-int-int-). Result: Based on benchmark from JOOQ’s post (https://blog.jooq.org/2017/10/11/benchmarking-jdk-string-replace-vs-apache-commons-stringutils-replace): Benchmark Mode Cnt Score Error Units StringReplaceBenchmark.testFastStringReplaceLongStringOneMatch thrpt 21 7546534,219 ± 145523,962 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringOneMatch thrpt 21 7353512,552 ± 124498,228 ops/s StringReplaceBenchmark.testFastStringReplaceLongStringSeveralMatches thrpt 21 5077255,810 ± 62358,937 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringSeveralMatches thrpt 21 4108357,612 ± 92909,038 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringOneMatch thrpt 21 15911221,949 ± 541064,693 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringOneMatch thrpt 21 10677897,475 ± 491091,973 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringSeveralMatches thrpt 21 9271742,251 ± 220150,121 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringSeveralMatches thrpt 21 6158829,188 ± 99637,607 ops/s {quote} source: https://github.com/apache/commons-lang/pull/300 was: {quote} StringUtils#replace uses substring to append a String region into a StringBuilder. This causes useless copies, as StringBuilder#append can take start and end indexes. Modification: Use proper StringBuilder#append overload (https://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html#append-java.lang.CharSequence-int-int-). Result: Based on benchmark from JOOQ’s post (https://blog.jooq.org/2017/10/11/benchmarking-jdk-string-replace-vs-apache-commons-stringutils-replace): Benchmark Mode Cnt Score Error Units StringReplaceBenchmark.testFastStringReplaceLongStringOneMatch thrpt 21 7546534,219 ± 145523,962 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringOneMatch thrpt 21 7353512,552 ± 124498,228 ops/s StringReplaceBenchmark.testFastStringReplaceLongStringSeveralMatches thrpt 21 5077255,810 ± 62358,937 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringSeveralMatches thrpt 21 4108357,612 ± 92909,038 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringOneMatch thrpt 21 15911221,949 ± 541064,693 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringOneMatch thrpt 21 10677897,475 ± 491091,973 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringSeveralMatches thrpt 21 9271742,251 ± 220150,121 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringSeveralMatches thrpt 21 6158829,188 ± 99637,607 ops/s {quote} source: https://github.com/apache/commons-lang/pull/300 > Improve StringUtils#replace throughput > -- > > Key: LANG-1358 > URL: https://issues.apache.org/jira/browse/LANG-1358 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 3.6 >Reporter: Pascal Schumacher >Priority: Minor > > {quote} > StringUtils#replace uses substring to append a String region into a > StringBuilder. This causes useless copies, as StringBuilder#append can take > start and end indexes. > Modification: > Use proper StringBuilder#append overload > (https://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html#append-java.lang.CharSequence-int-int-). > Result: > Based on benchmark from JOOQ’s post > (https://blog.jooq.org/2017/10/11/benchmarking-jdk-string-replace-vs-apache-commons-stringutils-replace): > Benchmark Mode Cnt Score Error Units > StringReplaceBenchmark.testFastStringReplaceLongStringOneMatch thrpt 21 > 7546534,219 ± 145523,962 ops/s > StringReplaceBenchmark.testStringUtilsReplaceLongStringOneMatch thrpt > 21 7353512,552 ± 124498,228 ops/s > StringReplaceBenchmark.testFastStringReplaceLongStringSeveralMatches > thrpt 21 5077255,810 ± 62358,937 ops/s > StringReplaceBenchmark.testStringUtilsReplaceLongStringSeveralMatches > thrpt 21 4108357,612 ± 92909,038 ops/s > StringReplaceBenchmark.testFastStringReplaceShortStringOneMatch thrpt > 21 15911221,949 ± 541064,693 ops/s > StringReplaceBenchmark.testStringUtilsReplaceShortStringOneMatch thrpt > 21 10677897,475 ± 491091,973 ops/s > StringReplaceBenchmark.testFastStringReplaceShortStringSeveralMatches > thrpt 21 9271742,251 ± 220150,121 ops/s > StringReplaceBenchmark.testStringUtilsReplaceShortStringSeveralMatches > thrpt 21 6158829,188 ± 99637,607 ops/s > {quote} > source: https://github.com/apache/c
[jira] [Updated] (OGNL-258) StringConverter from 3.1.15 version (included in 2.5.13)
[ https://issues.apache.org/jira/browse/OGNL-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amaury updated OGNL-258: Priority: Major (was: Critical) > StringConverter from 3.1.15 version (included in 2.5.13) > > > Key: OGNL-258 > URL: https://issues.apache.org/jira/browse/OGNL-258 > Project: Commons OGNL > Issue Type: Bug >Reporter: Amaury > > Hi Apache / Struts 2 team, > We've just discovered a bug with the new version 2.5.13 of Struts 2, mainly > in OGNL dependency. This is not the case with 2.5.10. > *Scenario*: we have a boolean method in a "if" condition statement in FTL > view. This method takes on argument which is a String ID in the format "X.Y" > (ex: "1.1). > *Result obtained during the OGNL parsing*: StringConverter is called > according to the "locale" of the browser and apparently with "fr_FR" locale, > the "X.Y" is converted to decimal format "X,Y" which is wrong since we want > to stick with our ID as it arrives. > It seems with en_US locale, the decimal conversion doesn't happen. > *Result expected*: the ID "X.Y" goes to the "if" statement as it is, not > converted in fr_Fr locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OGNL-258) StringConverter from 3.1.15 version (included in 2.5.13)
Amaury created OGNL-258: --- Summary: StringConverter from 3.1.15 version (included in 2.5.13) Key: OGNL-258 URL: https://issues.apache.org/jira/browse/OGNL-258 Project: Commons OGNL Issue Type: Bug Reporter: Amaury Priority: Critical Hi Apache / Struts 2 team, We've just discovered a bug with the new version 2.5.13 of Struts 2, mainly in OGNL dependency. This is not the case with 2.5.10. *Scenario*: we have a boolean method in a "if" condition statement in FTL view. This method takes on argument which is a String ID in the format "X.Y" (ex: "1.1). *Result obtained during the OGNL parsing*: StringConverter is called according to the "locale" of the browser and apparently with "fr_FR" locale, the "X.Y" is converted to decimal format "X,Y" which is wrong since we want to stick with our ID as it arrives. It seems with en_US locale, the decimal conversion doesn't happen. *Result expected*: the ID "X.Y" goes to the "if" statement as it is, not converted in fr_Fr locale. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()
[ https://issues.apache.org/jira/browse/JCS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated JCS-184: --- Fix Version/s: jcs-3.0 > Unexpected dispose() in CompositeCacheManager.release() > --- > > Key: JCS-184 > URL: https://issues.apache.org/jira/browse/JCS-184 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.2 >Reporter: at >Assignee: Bruno P. Kinoshita > Fix For: jcs-3.0 > > > If debug-logging is *not* enabled the return-statement is ignored and the > code falls-through to cache.dispose(). > See Line 739 in > http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806&view=markup -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()
[ https://issues.apache.org/jira/browse/JCS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201739#comment-16201739 ] Bruno P. Kinoshita commented on JCS-184: That worked [~tv], thanks. I've assigned to me. In the changes.xml I added it under the current open release, 3.0. But I noticed we have 2.2.1 in JIRA. Not sure which version I should choose for Fix Version here, so assigning 3.0 for now. Let me know if you know if it's better to leave empty, or maybe use 2.2.1. > Unexpected dispose() in CompositeCacheManager.release() > --- > > Key: JCS-184 > URL: https://issues.apache.org/jira/browse/JCS-184 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.2 >Reporter: at >Assignee: Bruno P. Kinoshita > Fix For: jcs-3.0 > > > If debug-logging is *not* enabled the return-statement is ignored and the > code falls-through to cache.dispose(). > See Line 739 in > http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806&view=markup -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()
[ https://issues.apache.org/jira/browse/JCS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated JCS-184: --- Assignee: Bruno P. Kinoshita > Unexpected dispose() in CompositeCacheManager.release() > --- > > Key: JCS-184 > URL: https://issues.apache.org/jira/browse/JCS-184 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.2 >Reporter: at >Assignee: Bruno P. Kinoshita > > If debug-logging is *not* enabled the return-statement is ignored and the > code falls-through to cache.dispose(). > See Line 739 in > http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806&view=markup -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()
[ https://issues.apache.org/jira/browse/JCS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201681#comment-16201681 ] Thomas Vandahl commented on JCS-184: Please try again. I added you to the list of committers for this project. > Unexpected dispose() in CompositeCacheManager.release() > --- > > Key: JCS-184 > URL: https://issues.apache.org/jira/browse/JCS-184 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.2 >Reporter: at > > If debug-logging is *not* enabled the return-statement is ignored and the > code falls-through to cache.dispose(). > See Line 739 in > http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806&view=markup -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang issue #300: Improve StringUtils#replace throughput
Github user slandelle commented on the issue: https://github.com/apache/commons-lang/pull/300 Note: `substring` overhead happens since Java 7 (since it actually does a copy). ---
[GitHub] commons-lang issue #300: Improve StringUtils#replace throughput
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/300 [![Coverage Status](https://coveralls.io/builds/13683982/badge)](https://coveralls.io/builds/13683982) Coverage remained the same at 95.199% when pulling **7280a495492c87680c6a13041bd3948f174a25a0 on slandelle:master** into **274dbfe81f5f43a47639623c62fc998b5eccd5f0 on apache:master**. ---
[GitHub] commons-lang pull request #300: Improve StringUtils#replace throughput
GitHub user slandelle opened a pull request: https://github.com/apache/commons-lang/pull/300 Improve StringUtils#replace throughput Motivation: `StringUtils#replace` uses `substring` to append a String region into a StringBuilder. This causes useless copies, as `StringBuilder#append` can take start and end indexes. Modification: Use proper `StringBuilder#append` [overload](https://docs.oracle.com/javase/8/docs/api/java/lang/StringBui lder.html#append-java.lang.CharSequence-int-int-). Result: Based on benchmark from [JOOQâs post](https://blog.jooq.org/2017/10/11/benchmarking-jdk-string-replace-v s-apache-commons-stringutils-replace): ``` Benchmark Mode Cnt Score Error Units StringReplaceBenchmark.testFastStringReplaceLongStringOneMatch thrpt 21 7546534,219 ± 145523,962 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringOneMatch thrpt 21 7353512,552 ± 124498,228 ops/s StringReplaceBenchmark.testFastStringReplaceLongStringSeveralMatches thrpt 21 5077255,810 ± 62358,937 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringSeveralMatches thrpt 21 4108357,612 ± 92909,038 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringOneMatch thrpt 21 15911221,949 ± 541064,693 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringOneMatch thrpt 21 10677897,475 ± 491091,973 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringSeveralMatches thrpt 21 9271742,251 ± 220150,121 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringSeveralMatches thrpt 21 6158829,188 ± 99637,607 ops/s ``` You can merge this pull request into a Git repository by running: $ git pull https://github.com/slandelle/commons-lang master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/300.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #300 commit 7280a495492c87680c6a13041bd3948f174a25a0 Author: Stephane Landelle Date: 2017-10-12T08:41:53Z Improve StringUtils#replace throughput Motivation: `StringUtils#replace` uses `substring` to append a String region into a StringBuilder. This causes useless copies, as `StringBuilder#append` can take start and end indexes. Modification: Use proper `StringBuilder#append` [overload](https://docs.oracle.com/javase/8/docs/api/java/lang/StringBui lder.html#append-java.lang.CharSequence-int-int-). Result: Based on benchmark from [JOOQâs post](https://blog.jooq.org/2017/10/11/benchmarking-jdk-string-replace-v s-apache-commons-stringutils-replace): ``` Benchmark Mode Cnt Score Error Units StringReplaceBenchmark.testFastStringReplaceLongStringOneMatch thrpt 21 7546534,219 ± 145523,962 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringOneMatch thrpt 21 7353512,552 ± 124498,228 ops/s StringReplaceBenchmark.testFastStringReplaceLongStringSeveralMatches thrpt 21 5077255,810 ± 62358,937 ops/s StringReplaceBenchmark.testStringUtilsReplaceLongStringSeveralMatches thrpt 21 4108357,612 ± 92909,038 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringOneMatch thrpt 21 15911221,949 ± 541064,693 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringOneMatch thrpt 21 10677897,475 ± 491091,973 ops/s StringReplaceBenchmark.testFastStringReplaceShortStringSeveralMatches thrpt 21 9271742,251 ± 220150,121 ops/s StringReplaceBenchmark.testStringUtilsReplaceShortStringSeveralMatches thrpt 21 6158829,188 ± 99637,607 ops/s ``` ---
[jira] [Commented] (VALIDATOR-429) UrlValidator - path is invalid due to using java.net.URI for validation (regression)
[ https://issues.apache.org/jira/browse/VALIDATOR-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201587#comment-16201587 ] Bruno P. Kinoshita commented on VALIDATOR-429: -- Might be easier to review the suggested changes if there is a pull request in GitHub, or a patch attached (former is preferable IMO). Might have time to give it a try and review it in the next days. > UrlValidator - path is invalid due to using java.net.URI for validation > (regression) > > > Key: VALIDATOR-429 > URL: https://issues.apache.org/jira/browse/VALIDATOR-429 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.6 >Reporter: limpygnome > Labels: easyfix > > h1. Summary > We've been hit by a bug in a real world application after upgrading 1.4.1 to > 1.6, where previously valid URLs are no longer valid, which looks to be due > to using java.net.URI for validating the path of a URL. > h1. Steps to Reproduce > Our application went to validate URLs similar to the following: > * http://example.com//_test > This is no longer valid in 1.6.1, but the following cases are: > * http://example.com//test > * http://example.com/_test > h1. Impact > It seems paths in UrlValidator are being parsed/validated as host-names, per > java.net.URI's validation. > h1. Technical > It looks like this may have been introduced by the following change: > https://github.com/apache/commons-validator/commit/03bf0d33143ebd13e4f389cd4ecac8aec17c2057 > Specifically due to now using java.net.URI to validate a path. The usage is > as follows in org.apache.commons.validator.routines.UrlValidator: > {code} > URI uri = new URI(null,null,path,null); > {code} > It looks like URI is trying to parse the path as a hostname when the schema > and hostname are not specified. > Example to reproduce: > {code} > new URI(null, null, "//_test", null); // throws URISyntaxException > {code} > Same example with other parts, no longer throwing exception: > {code} > new URI(null, "test", "//_test", null); > {code} > Even though java.net.URI states string components can be null, it seems the > URL built internally, which is validated, is slightly different. So when > specifying a hostname with URI, internally it constructs: > * //test//_test > Using no hostname, in the same way as UrlValidator, the following is > constructed and validated internally: > * //_test > Therefore it looks like there's either a bug in java.net.URI, or its usage is > not correctly documented. > h1. Fix > A potential fix is to change > org.apache.commons.validator.routines.UrlValidator to pass an empty string in > the hostname. Internally, in java.net.URI, this produces: > * _test > Thus the hostname is empty, which is considered empty, and the correct path > is validated. > Would this fix be appropriate, or considered too fragile? > Alternatively the fix could be to extract similar logic to java.net.URI, to > validate the path, which appears to be just checking the characters are valid > and between a certain range. This logic can be seen in > java.net.URI.parseHierarchical, which calls upon checkChars. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-662) Build failures when building with Java 9
[ https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201583#comment-16201583 ] ASF GitHub Bot commented on COLLECTIONS-662: Github user asfgit closed the pull request at: https://github.com/apache/commons-collections/pull/30 > Build failures when building with Java 9 > > > Key: COLLECTIONS-662 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-662 > Project: Commons Collections > Issue Type: Bug >Reporter: Vamsi > > *mvn clean test* fails with following errors when using with java-9 > {code:java} > Tests in error: > MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration > sun.util.locale.prov... > MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration > sun.util.locale.pro... > MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration > sun.util.locale.prov... > MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration > sun.util.locale.provi... > MapUtilsTest.testgetLongValue:992 » ServiceConfiguration > sun.util.locale.provi... > MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration > sun.util.locale.pro... > ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration > sun.util.locale > Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0 > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-662) Build failures when building with Java 9
[ https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201584#comment-16201584 ] ASF GitHub Bot commented on COLLECTIONS-662: Github user asfgit closed the pull request at: https://github.com/apache/commons-collections/pull/30 > Build failures when building with Java 9 > > > Key: COLLECTIONS-662 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-662 > Project: Commons Collections > Issue Type: Bug >Reporter: Vamsi > > *mvn clean test* fails with following errors when using with java-9 > {code:java} > Tests in error: > MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration > sun.util.locale.prov... > MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration > sun.util.locale.pro... > MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration > sun.util.locale.prov... > MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration > sun.util.locale.provi... > MapUtilsTest.testgetLongValue:992 » ServiceConfiguration > sun.util.locale.provi... > MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration > sun.util.locale.pro... > ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration > sun.util.locale > Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0 > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-662) Build failures when building with Java 9
[ https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201582#comment-16201582 ] ASF GitHub Bot commented on COLLECTIONS-662: Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-collections/pull/30 Thanks! > Build failures when building with Java 9 > > > Key: COLLECTIONS-662 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-662 > Project: Commons Collections > Issue Type: Bug >Reporter: Vamsi > > *mvn clean test* fails with following errors when using with java-9 > {code:java} > Tests in error: > MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration > sun.util.locale.prov... > MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration > sun.util.locale.pro... > MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration > sun.util.locale.prov... > MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration > sun.util.locale.provi... > MapUtilsTest.testgetLongValue:992 » ServiceConfiguration > sun.util.locale.provi... > MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration > sun.util.locale.pro... > ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration > sun.util.locale > Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0 > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-552) FilenameUtils.concat fails if second argument (fullFilenameToAdd) starts with '~' (tilde)
[ https://issues.apache.org/jira/browse/IO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201579#comment-16201579 ] Bruno P. Kinoshita commented on IO-552: --- Interesting. I didn't know, but looks like in Linux ~kinow is equivalent to /home/kinow, or to ~ if kinow is the currently logged-in user. My user is kinow, and trying `mkdir ~kinow` fails with directory already exists. But a random `mkdir ~jj` works. But so does `touch ~123`. Which means you can have a file or directory that starts with ~. The [getPrefixLength() method|https://github.com/apache/commons-io/blob/43720d02405e0b96939b331c1be7812fe5fec877/src/main/java/org/apache/commons/io/FilenameUtils.java#L651] seems to assume that a file like ~kinow is going to be a directory. Thus moving the prefix to the last character + 1. When that happens, the [doNormalize()|https://github.com/apache/commons-io/blob/43720d02405e0b96939b331c1be7812fe5fec877/src/main/java/org/apache/commons/io/FilenameUtils.java#L348] simply appends the / to the end of the file name. Altering the getPrefixLength() method to return 0 instead of the length+1 for the case in question, results in "c:/temp/~abc.txt", which I believe is the intended output. However, this change also breaks 7 tests. {noformat} Results : Failed tests: FilenameUtilsTestCase.testConcat:474 expected:<[~user/]> but was:<[a/b/~user]> FilenameUtilsTestCase.testGetFullPath:744 expected:<[~user/]> but was:<[]> FilenameUtilsTestCase.testGetFullPathNoEndSeparator:779 expected:<[~user]> but was:<[]> FilenameUtilsTestCase.testGetPrefix:603 expected:<[~user/]> but was:<[]> FilenameUtilsTestCase.testGetPrefixLength:535 expected:<6> but was:<0> FilenameUtilsTestCase.testNormalize:192 expected:<~user[/]> but was:<~user[]> FilenameUtilsTestCase.testNormalizeNoEndSeparator:368 expected:<~user[/]> but was:<~user[]> Tests run: 1318, Failures: 7, Errors: 0, Skipped: 4 {noformat} Not sure how to fix it now. Might need to think about it some more. But would be easier if someone else chimed in to add a second opinion or alternatives. At work I am using FilenameUtils for parsing some file names in RESTful URL's. So might get some extra time to work on it if it impact us. > FilenameUtils.concat fails if second argument (fullFilenameToAdd) starts with > '~' (tilde) > - > > Key: IO-552 > URL: https://issues.apache.org/jira/browse/IO-552 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.2, 2.5 > Environment: Windows 7 64bit, JavaVM 1.8 32bit >Reporter: Jochen Tümmers >Priority: Critical > > {{FilenameUtils.concat("c:/temp", "~abc.txt") returns "~abc.txt/" instead of > "c:/temp/~abc.txt".}} > As a result, the file would be created in the user's home directory instead > of c:/temp. > (Note: I Had to replace all instances of double backslashes that would > normally appear in the java code with forward slashes as the editor cannot > handle backslashes properly.) > commons io 2.2. and 2.5 behave the same. 2.3 and 2.4 not tested. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-552) FilenameUtils.concat fails if second argument (fullFilenameToAdd) starts with '~' (tilde)
[ https://issues.apache.org/jira/browse/IO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201556#comment-16201556 ] Bruno P. Kinoshita commented on IO-552: --- FWIW, checked out the latest code, quickly tried the provided sample code, and successfully reproduced the issue. > FilenameUtils.concat fails if second argument (fullFilenameToAdd) starts with > '~' (tilde) > - > > Key: IO-552 > URL: https://issues.apache.org/jira/browse/IO-552 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.2, 2.5 > Environment: Windows 7 64bit, JavaVM 1.8 32bit >Reporter: Jochen Tümmers >Priority: Critical > > {{FilenameUtils.concat("c:/temp", "~abc.txt") returns "~abc.txt/" instead of > "c:/temp/~abc.txt".}} > As a result, the file would be created in the user's home directory instead > of c:/temp. > (Note: I Had to replace all instances of double backslashes that would > normally appear in the java code with forward slashes as the editor cannot > handle backslashes properly.) > commons io 2.2. and 2.5 behave the same. 2.3 and 2.4 not tested. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()
[ https://issues.apache.org/jira/browse/JCS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201550#comment-16201550 ] Bruno P. Kinoshita commented on JCS-184: Fixed in r1811915. For some reason I cannot assign this issue to myself, nor change its status. Will post a question on the mailing list to see if someone knows what's wrong, or if I would need to contact infra. Thank you for reporting the issue. I've added a small unit test (couldn't find a unit test class specifically for the CompositeCacheManager so created one), and also a note in changes.xml with credit to your user in JIRA. Cheers Bruno > Unexpected dispose() in CompositeCacheManager.release() > --- > > Key: JCS-184 > URL: https://issues.apache.org/jira/browse/JCS-184 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.2 >Reporter: at > > If debug-logging is *not* enabled the return-statement is ignored and the > code falls-through to cache.dispose(). > See Line 739 in > http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806&view=markup -- This message was sent by Atlassian JIRA (v6.4.14#64029)