[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 [](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)
