[jira] [Commented] (TEXT-126) Dice's Coefficient Algorithm in String similarity

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706274#comment-16706274
 ] 

Pascal Schumacher commented on TEXT-126:


Contributions welcome!

> Dice's Coefficient Algorithm in String similarity
> -
>
> Key: TEXT-126
> URL: https://issues.apache.org/jira/browse/TEXT-126
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Vicky Chawda
>Priority: Major
>
> I'd like to propose an extension to the algorithms for string similarity in 
> *commons-text/src/main/java/org/apache/commons/text/similarity/*
>  Dice's Coefficient Algorithm can be helpful for many who are looking for 
> ranking similarities in strings.
> *Inspired from* - [http://www.catalysoft.com/articles/StrikeAMatch.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-96) Convenience methods needed for RandomStringGenerator

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-96.
-
   Resolution: Fixed
Fix Version/s: (was: 1.x)

I'm closing this issue as commons-lang RandomStringUtils was "undeprecated" and 
some work has been done to make RandomStringGenerator easier to use.

> Convenience methods needed for RandomStringGenerator
> 
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated 
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new 
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate 
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point 
> is in the first place so then trying to get our automation testers to use the 
> new API to implement random alphanumeric character generation would be 
> difficult.
> I therefore suggest that commons-text should have a copy of 
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or 
> alternatively convenience static methods for the common use cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-134) Add a Properties file string lookup

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-134.
--
   Resolution: Fixed
Fix Version/s: (was: 1.6)
   1.5

I'm closing this issue as it was released as part of 1.5. Changes should be 
discussed in a new issue imho.

> Add a Properties file string lookup
> ---
>
> Key: TEXT-134
> URL: https://issues.apache.org/jira/browse/TEXT-134
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.5
>
>
> Add a Properties file String Lookup to look up the value for a given key in 
> the format "Document:Key".
> For example: "com/domain/document.properties::key".
> Note the use of the separator "::" instead of ":" to allow for path 
> containing ":" like "C:\path\to\file.properties".
> The lookup key is "properties".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-137) Add a URL string lookup

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-137.
--
Resolution: Fixed

I'm closing this issue as it was released as part of 1.5. Removing/Changing it 
should be part of new issue imho.

> Add a URL string lookup
> ---
>
> Key: TEXT-137
> URL: https://issues.apache.org/jira/browse/TEXT-137
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.5
>
>
> Add a simple URL string lookup to read the contents of a URL. This is _not_ a 
> full fledged HTTP client.
> For example, using the HTTP scheme: 
> "UTF-8:[http://www.google.com|http://www.google.com/];
> For example, using the file scheme: 
> "UTF-8:file:///C:/somehome/commons/commons-text/src/test/resources/document.properties"
> The URL lookup key is "url"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-135) Add a script string lookup

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-135.
--
   Resolution: Fixed
Fix Version/s: 1.5

> Add a script string lookup
> --
>
> Key: TEXT-135
> URL: https://issues.apache.org/jira/browse/TEXT-135
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.5
>
>
> Add a script file string lookup.
> Example key: "javascript:\"Hello World!\""
> The lookup key is "script".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-137) Add a URL string lookup

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-137:
---
Fix Version/s: 1.5

> Add a URL string lookup
> ---
>
> Key: TEXT-137
> URL: https://issues.apache.org/jira/browse/TEXT-137
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.5
>
>
> Add a simple URL string lookup to read the contents of a URL. This is _not_ a 
> full fledged HTTP client.
> For example, using the HTTP scheme: 
> "UTF-8:[http://www.google.com|http://www.google.com/];
> For example, using the file scheme: 
> "UTF-8:file:///C:/somehome/commons/commons-text/src/test/resources/document.properties"
> The URL lookup key is "url"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-135) Add a script string lookup

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-135:
---
Fix Version/s: (was: 1.6)

> Add a script string lookup
> --
>
> Key: TEXT-135
> URL: https://issues.apache.org/jira/browse/TEXT-135
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add a script file string lookup.
> Example key: "javascript:\"Hello World!\""
> The lookup key is "script".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-131) JaroWinklerDistance: Calculation deviates from definition

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-131.
--
   Resolution: Fixed
Fix Version/s: 1.5

> JaroWinklerDistance: Calculation deviates from definition
> -
>
> Key: TEXT-131
> URL: https://issues.apache.org/jira/browse/TEXT-131
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Jan Martin Keil
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.5
>
>
> The calculation in {{JaroWinklerDistance}} deviates from the definition of 
> the Jaro-Winkler Similarity. By definition the common prefix length is only 
> determine for the first 4 characters. Further, the JaroWinkler is defined as 
> {{JaroSimilarity + ScalingFactor * CommonPrefixLength * (1 - JaroSimilarity 
> )}}.
>  Therefore, I recommend the following changes:
>  # Update Jaro-Winkler Similarity calculation
> {code:java}
> final double jw = j < 0.7D ? j : j + Math.min(defaultScalingFactor, 1D / 
> mtp[3]) * mtp[2] * (1D - j);
> {code}
> to
> {code:java}
> final double jw = j < 0.7D ? j : j + defaultScalingFactor * mtp[2] * (1D - j);
> {code}
>  # Update calculation of Common Prefix Length
> {code:java}
> for (int mi = 0; mi < min.length(); mi++) {
> {code}
> to
> {code:java}
> for (int mi = 0; mi < Math.min(4, min.length()); mi++) {
> {code}
>  # Remove unnecessary return value
> {code:java}
> return new int[] {matches, transpositions, prefix, max.length()};
> {code}
> to
> {code:java}
> return new int[] {matches, transpositions, prefix};
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-131) JaroWinklerDistance: Calculation deviates from definition

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-131:
---
Affects Version/s: 1.4

> JaroWinklerDistance: Calculation deviates from definition
> -
>
> Key: TEXT-131
> URL: https://issues.apache.org/jira/browse/TEXT-131
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Jan Martin Keil
>Assignee: Rob Tompkins
>Priority: Major
>
> The calculation in {{JaroWinklerDistance}} deviates from the definition of 
> the Jaro-Winkler Similarity. By definition the common prefix length is only 
> determine for the first 4 characters. Further, the JaroWinkler is defined as 
> {{JaroSimilarity + ScalingFactor * CommonPrefixLength * (1 - JaroSimilarity 
> )}}.
>  Therefore, I recommend the following changes:
>  # Update Jaro-Winkler Similarity calculation
> {code:java}
> final double jw = j < 0.7D ? j : j + Math.min(defaultScalingFactor, 1D / 
> mtp[3]) * mtp[2] * (1D - j);
> {code}
> to
> {code:java}
> final double jw = j < 0.7D ? j : j + defaultScalingFactor * mtp[2] * (1D - j);
> {code}
>  # Update calculation of Common Prefix Length
> {code:java}
> for (int mi = 0; mi < min.length(); mi++) {
> {code}
> to
> {code:java}
> for (int mi = 0; mi < Math.min(4, min.length()); mi++) {
> {code}
>  # Remove unnecessary return value
> {code:java}
> return new int[] {matches, transpositions, prefix, max.length()};
> {code}
> to
> {code:java}
> return new int[] {matches, transpositions, prefix};
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-130) JaroWinklerDistance: Wrong results due to precision of transpositions

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-130:
---
Affects Version/s: 1.4

> JaroWinklerDistance: Wrong results due to precision of transpositions
> -
>
> Key: TEXT-130
> URL: https://issues.apache.org/jira/browse/TEXT-130
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Jan Martin Keil
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.5
>
>
> The method {{JaroWinklerDistance#matches}} returns {{transpositions / 2}} as 
> integer. However, it is not granted for {{transpositions}} to be even. E.g. 
> comparing "aaabcd" and "aaacdb" will result in {{transpositions}} = 3. 
> Therefore the method must return 1.5, not 1. Otherwise the similarity is 
> 0.9611 instead of 0.9417.
> I recommend to return {{halfTranspositions}} instead of {{transpositions}} 
> and doing the cast and division ({{(double) mtp[1] / 2}}) in 
> {{JaroWinklerDistance#apply}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-130) JaroWinklerDistance: Wrong results due to precision of transpositions

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-130.
--
   Resolution: Fixed
Fix Version/s: 1.5

> JaroWinklerDistance: Wrong results due to precision of transpositions
> -
>
> Key: TEXT-130
> URL: https://issues.apache.org/jira/browse/TEXT-130
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Jan Martin Keil
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.5
>
>
> The method {{JaroWinklerDistance#matches}} returns {{transpositions / 2}} as 
> integer. However, it is not granted for {{transpositions}} to be even. E.g. 
> comparing "aaabcd" and "aaacdb" will result in {{transpositions}} = 3. 
> Therefore the method must return 1.5, not 1. Otherwise the similarity is 
> 0.9611 instead of 0.9417.
> I recommend to return {{halfTranspositions}} instead of {{transpositions}} 
> and doing the cast and division ({{(double) mtp[1] / 2}}) in 
> {{JaroWinklerDistance#apply}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1401) Typo in JavaDoc for lastIndexOf

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1401.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.8

Thanks for reporting!

> Typo in JavaDoc for lastIndexOf
> ---
>
> Key: LANG-1401
> URL: https://issues.apache.org/jira/browse/LANG-1401
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Alex Mamedov
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.8
>
>
> Typo in Java doc for lastIndexOf.
> You could check on following page:
> [https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html#lastIndexOf-java.lang.CharSequence-java.lang.CharSequence-int-]
> In example of execution two last row have same arguments but result differ:
> StringUtils.lastIndexOf("aabaabaa", "ba", 2) = -1
> StringUtils.lastIndexOf("aabaabaa", "ba", 2) = 2
>  
> Thanks
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1392) StringUtils.firstNonBlank and firstNonEmpty

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1392.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.8

> StringUtils.firstNonBlank and firstNonEmpty
> ---
>
> Key: LANG-1392
> URL: https://issues.apache.org/jira/browse/LANG-1392
> Project: Commons Lang
>  Issue Type: New Feature
>Reporter: Jeffrey P Nelson
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 3.8
>
>
> 2 new methods in *StringUtils* that for retrieving the first *CharSequence* 
> in a list that is not blank or not empty. These will follow the same pattern 
> as is used in *ObjectUtils.firstNonNull(T ... values)*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-118) JSON escaping incorrect for the delete control character

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479579#comment-16479579
 ] 

Pascal Schumacher commented on TEXT-118:


Pull request welcome! :-)

> JSON escaping incorrect for the delete control character
> 
>
> Key: TEXT-118
> URL: https://issues.apache.org/jira/browse/TEXT-118
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
> Environment: JDK8u162, Mac OS X 13.something.
>Reporter: Dan Wallach
>Priority: Minor
>
> Here's a simple unit test. The assertion about backspace succeeds. The 
> assertion about the delete character fails. Instead, the delete character 
> shows up in the escaped text. This violates the JSON spec, which forbids 
> "control characters" in strings.
> {code:java}
> @Test
> public void testDeleteCharacter() {
>   String backspaceString = "Backspace: \b";
>   String deleteString = "Delete: \u007F";
>   assertEquals("Backspace: \\b", 
> StringEscapeUtils.escapeJson(backspaceString));
>   assertEquals("Delete: \\u007F", StringEscapeUtils.escapeJson(deleteString));
> }
> {code}
>  
> The JSON spec doesn't have a specific escape for a delete character, but it 
> does explicitly exclude control characters from passing through. I'd 
> recommend behavior as in the above unit test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-120) StringEscapeUtils#unescapeJson does not unescape double quotes and forward slash

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-120:
---
Affects Version/s: 1.3

> StringEscapeUtils#unescapeJson does not unescape double quotes and forward 
> slash
> 
>
> Key: TEXT-120
> URL: https://issues.apache.org/jira/browse/TEXT-120
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2, 1.3
>Reporter: Pedro Robles
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 1.4
>
>
> Here's a unit test to show how the escape/unescape cycle doesn't return 
> expected String.
>  
> {code:java}
> @Test
> public void testUnscape() {
>   String unscapeString = "double quote: \" and a forward slash: /";
>   String escapeString = StringEscapeUtils.escapeJson(unscapeString);
>   assertEquals("double quote: \" and a forward slash: \/", escapeString);
>   assertEquals(unscapeString, StringEscapeUtils.unescapeJson(escapeString));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-16) Make HumanNameParser configurable

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-16.
-
   Resolution: Won't Fix
 Assignee: (was: Benedikt Ritter)
Fix Version/s: (was: 1.x)

As HumanNameParser was removed from commons-text I am closing this.

> Make HumanNameParser configurable
> -
>
> Key: TEXT-16
> URL: https://issues.apache.org/jira/browse/TEXT-16
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>  Labels: Refactoring
>
> From http://markmail.org/thread/da7ayocit2dl4otv
> - The constructor of the parser takes configuration options which can be
> reused for several names to parse
> - the parse method takes a string as parameter, containing a name
> - the parse method returns an immutable Name objects which has getters for
> firstName, lastName etc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TEXT-120) StringEscapeUtils#unescapeJson does not unescape double quotes and forward slash

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-120.

   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 1.4

Fixed. Thanks for reporting!

> StringEscapeUtils#unescapeJson does not unescape double quotes and forward 
> slash
> 
>
> Key: TEXT-120
> URL: https://issues.apache.org/jira/browse/TEXT-120
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Pedro Robles
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 1.4
>
>
> Here's a unit test to show how the escape/unescape cycle doesn't return 
> expected String.
>  
> {code:java}
> @Test
> public void testUnscape() {
>   String unscapeString = "double quote: \" and a forward slash: /";
>   String escapeString = StringEscapeUtils.escapeJson(unscapeString);
>   assertEquals("double quote: \" and a forward slash: \/", escapeString);
>   assertEquals(unscapeString, StringEscapeUtils.unescapeJson(escapeString));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-120) StringEscapeUtils UnescapeJson does not unescape double quotes and forward slash

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-120:
---
Summary: StringEscapeUtils UnescapeJson does not unescape double quotes and 
forward slash  (was: StringEscapeUtils UnescapeJson does not unescape)

> StringEscapeUtils UnescapeJson does not unescape double quotes and forward 
> slash
> 
>
> Key: TEXT-120
> URL: https://issues.apache.org/jira/browse/TEXT-120
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Pedro Robles
>Priority: Major
>
> Here's a unit test to show how the escape/unescape cycle doesn't return 
> expected String.
>  
> {code:java}
> @Test
> public void testUnscape() {
>   String unscapeString = "double quote: \" and a forward slash: /";
>   String escapeString = StringEscapeUtils.escapeJson(unscapeString);
>   assertEquals("double quote: \" and a forward slash: \/", escapeString);
>   assertEquals(unscapeString, StringEscapeUtils.unescapeJson(escapeString));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-120) StringEscapeUtils#unescapeJson does not unescape double quotes and forward slash

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-120:
---
Summary: StringEscapeUtils#unescapeJson does not unescape double quotes and 
forward slash  (was: StringEscapeUtils UnescapeJson does not unescape double 
quotes and forward slash)

> StringEscapeUtils#unescapeJson does not unescape double quotes and forward 
> slash
> 
>
> Key: TEXT-120
> URL: https://issues.apache.org/jira/browse/TEXT-120
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Pedro Robles
>Priority: Major
>
> Here's a unit test to show how the escape/unescape cycle doesn't return 
> expected String.
>  
> {code:java}
> @Test
> public void testUnscape() {
>   String unscapeString = "double quote: \" and a forward slash: /";
>   String escapeString = StringEscapeUtils.escapeJson(unscapeString);
>   assertEquals("double quote: \" and a forward slash: \/", escapeString);
>   assertEquals(unscapeString, StringEscapeUtils.unescapeJson(escapeString));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (DBCP-476) AbandonedTrace.getTrace() contains race condition

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DBCP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved DBCP-476.

   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 2.3.0

> AbandonedTrace.getTrace() contains race condition
> -
>
> Key: DBCP-476
> URL: https://issues.apache.org/jira/browse/DBCP-476
> Project: Commons DBCP
>  Issue Type: Bug
>Reporter: Richard Cordova
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.3.0
>
>
> The clean up code in AbandonedTrace is subject to the reference being cleared 
> in between the condition being checked and the referent being added to the 
> result.
> {code}
> while (iter.hasNext()) {
> WeakReference ref = iter.next();
> if (ref.get() == null) {
> // Clean-up since we are here anyway
> iter.remove();
> } else {
> result.add(ref.get());
> }
> }
> {code}
> This can surface as a NullPointerException, e.g.
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.tomcat.dbcp.dbcp2.DelegatingStatement.close(DelegatingStatement.java:149)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1391) Improve Javadoc for StringUtils.isAnyEmpty(null)

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1391:

Priority: Minor  (was: Major)

> Improve Javadoc for StringUtils.isAnyEmpty(null) 
> -
>
> Key: LANG-1391
> URL: https://issues.apache.org/jira/browse/LANG-1391
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.7
>Reporter: Sauro Matulli
>Priority: Minor
> Fix For: 3.8
>
>
>  
> The StringUtils.isAnyEmpty(null) method returns an incorrect value from what 
> is specified in the javadoc.
> JAVADOC:   StringUtils.isAnyEmpty(null) = true
> Test: System.out.println("" + StringUtils.isAnyEmpty(null));  --> false
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IO-535) Thread bug in FileAlterationMonitor#stop(int)

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved IO-535.
--
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 2.7

> Thread bug in FileAlterationMonitor#stop(int)
> -
>
> Key: IO-535
> URL: https://issues.apache.org/jira/browse/IO-535
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.5
> Environment: Components managed by a DI Framework
>Reporter: Anthony RAYMOND
>Assignee: Pascal Schumacher
>Priority: Critical
>  Labels: easyfix, patch, performance
> Fix For: 2.7
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> The thread in FileAlterationMonitor wasn't stopped by the `stop(int)` method, 
> which forbid application to shutdown until all `Thread` are exited (if 
> FileAlterationMonitor is part of a DI managed component).
> This behavior conflict with the method javadoc `@param stopInterval the 
> amount of time in milliseconds to wait for the thread to finish.`
> h5. Simple example to understand
> Bad behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
>// Ok, we reach this point until 50ms are elapsed, but the thread is 
> still alive.
>//   because Thread#join(int) does not kill the thread. And the thread 
> remains alive.
> {code}
> Good behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
> t.interupt();
>// Thread is exited
> {code}
> In this case, we waited the given time BEFORE exiting the `Thread`, as 
> described in the javadoc, and the `Thread` is now finished and killed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IO-535) Thread bug in FileAlterationMonitor#stop(int)

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IO-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated IO-535:
-
Summary: Thread bug in FileAlterationMonitor#stop(int)  (was: Thread bug in 
FileAlterationMonitor)

> Thread bug in FileAlterationMonitor#stop(int)
> -
>
> Key: IO-535
> URL: https://issues.apache.org/jira/browse/IO-535
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.5
> Environment: Components managed by a DI Framework
>Reporter: Anthony RAYMOND
>Priority: Critical
>  Labels: easyfix, patch, performance
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> The thread in FileAlterationMonitor wasn't stopped by the `stop(int)` method, 
> which forbid application to shutdown until all `Thread` are exited (if 
> FileAlterationMonitor is part of a DI managed component).
> This behavior conflict with the method javadoc `@param stopInterval the 
> amount of time in milliseconds to wait for the thread to finish.`
> h5. Simple example to understand
> Bad behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
>// Ok, we reach this point until 50ms are elapsed, but the thread is 
> still alive.
>//   because Thread#join(int) does not kill the thread. And the thread 
> remains alive.
> {code}
> Good behavior
> {code:java}
> Thread t = new Thread(() -> {
> try {
> Thread.sleep(50);
> } catch (final InterruptedException e) {
> }
> });
> t.start();
> t.join(50);
> t.interupt();
>// Thread is exited
> {code}
> In this case, we waited the given time BEFORE exiting the `Thread`, as 
> described in the javadoc, and the `Thread` is now finished and killed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-119) StringEscapeUtils dropped SQL support but it is not clear if this is intentional or not

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425354#comment-16425354
 ] 

Pascal Schumacher commented on TEXT-119:


Thanks for reporting!

As far as I know neither commons-lang3 nor commons-text never supported SQL 
escaping. Commons-lang 2.x supported SQL escaping, but this was dropped in 3.0, 
see https://commons.apache.org/proper/commons-lang/article3_0.html for details.

I'm not aware of any other Java ASF project is providing this functionally, but 
there are a lot of projects so I may miss something.

I have removed the mention of SQL escaping from the commons-text userguide.

> StringEscapeUtils dropped SQL support but it is not clear if this is 
> intentional or not
> ---
>
> Key: TEXT-119
> URL: https://issues.apache.org/jira/browse/TEXT-119
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Scott Markwell
>Priority: Major
>  Labels: docuentation, roadmap
> Fix For: 1.4
>
>
> The Commons Text user guide indicates StringEscapeUtils supposed SQL as an 
> escape
> [http://commons.apache.org/proper/commons-text/userguide.html]
> Commons Lang3 indicates the functionality of 
> org.apache.commons.lang3.StringEscapeUtils was moved to Commons Text (which 
> does include SQL escape) and deprecates it's own implementation.
> [http://commons.apache.org/proper/commons-text/changes-report.html] Provides 
> no insight on the lack of SQL support
>  
> I'm not sure the correct path forward, as project intentions aren't clear.  
> If the project has no intention of supporting SQL, the user-guide should be 
> updated and notes about migrating from commons-lang3 should note that stance. 
>  Additionally if another Java ASF project is providing that functionality it 
> should be indicated.  If this is an oversight on inclusion in the Commons 
> Text project, then I guess this is a missing feature request.
> Thanks for all the great work
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TEXT-119) StringEscapeUtils dropped SQL support but it is not clear if this is intentional or not

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-119.

   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 1.4

> StringEscapeUtils dropped SQL support but it is not clear if this is 
> intentional or not
> ---
>
> Key: TEXT-119
> URL: https://issues.apache.org/jira/browse/TEXT-119
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Scott Markwell
>Assignee: Pascal Schumacher
>Priority: Major
>  Labels: docuentation, roadmap
> Fix For: 1.4
>
>
> The Commons Text user guide indicates StringEscapeUtils supposed SQL as an 
> escape
> [http://commons.apache.org/proper/commons-text/userguide.html]
> Commons Lang3 indicates the functionality of 
> org.apache.commons.lang3.StringEscapeUtils was moved to Commons Text (which 
> does include SQL escape) and deprecates it's own implementation.
> [http://commons.apache.org/proper/commons-text/changes-report.html] Provides 
> no insight on the lack of SQL support
>  
> I'm not sure the correct path forward, as project intentions aren't clear.  
> If the project has no intention of supporting SQL, the user-guide should be 
> updated and notes about migrating from commons-lang3 should note that stance. 
>  Additionally if another Java ASF project is providing that functionality it 
> should be indicated.  If this is an oversight on inclusion in the Commons 
> Text project, then I guess this is a missing feature request.
> Thanks for all the great work
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1384) NPE from SystemUtils.isJavaVersionAtLeast under Java 11 EA

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1384.
-
   Resolution: Fixed
 Assignee: Gilles
Fix Version/s: 3.8

> NPE from SystemUtils.isJavaVersionAtLeast under Java 11 EA
> --
>
> Key: LANG-1384
> URL: https://issues.apache.org/jira/browse/LANG-1384
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.7
> Environment: Java 11 EA
>Reporter: Ian Young
>Assignee: Gilles
>Priority: Major
> Fix For: 3.8
>
>
> Calling, for example, 
> {{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_7);}} under the Java 11 
> early access release causes a NPE:
> {code:java}
> java.lang.NullPointerException
> at 
> org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast(SystemUtils.java:1654)
> {code}
> This is:
> {code}
> return JAVA_SPECIFICATION_VERSION_AS_ENUM.atLeast(requiredVersion);
> {code}
> ... which implies that {{JAVA_SPECIFICATION_VERSION_AS_ENUM}} hasn't been 
> resolved properly, although it looks like the code in JavaVersion intends to 
> return {{JAVA_RECENT}} in the case of unknown versions.
> The {{java.specification.version}} system property is "11" in this 
> environment.
> {code}
> $ java -version
> java version "11-ea" 2018-09-18
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+2)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+2, mixed mode){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TEXT-25) Add a duration parser

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-25.
-
   Resolution: Won't Fix
 Assignee: (was: Bruno P. Kinoshita)
Fix Version/s: (was: 1.x)

Closing this as "Won't Fix" after reading the latest comments. Feel free to 
reopen if you disagree.

> Add a duration parser
> -
>
> Key: TEXT-25
> URL: https://issues.apache.org/jira/browse/TEXT-25
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>
> Duration parses interpret text such as *2 hours, 1 mn and 22sec*.
> Examples exist, such as https://github.com/jchampemont/gunip, written in 
> Javaby Jean Champémont, inspired by https://github.com/domchristie/juration 
> (JavaScript).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TEXT-80) StrLookup API confusing

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-80.
---
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: (was: 2.0)
   1.3

StrLookup will deprecated and replaced with StringLookup in 1.3.

> StrLookup API confusing
> ---
>
> Key: TEXT-80
> URL: https://issues.apache.org/jira/browse/TEXT-80
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Etienne Neveu
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 1.3
>
>
> [bayard: copying this from LANG-564]
> I don't see the point of having a generic type parameter on the StrLookup 
> class, if it's not used anywhere. No method / field in StrLookup references 
> this type parameter. IntelliJ IDEA itself reports a warning: "Type parameter 
> 'V' is never used". Moreover, Java generics are not reified, so there is no 
> reliable way to access the type parameter at runtime (and I don't see the 
> point of doing that anyway...).
> While the Javadoc tries to clarify the purpose of a StrLookup, the unused 
> type parameter is still confusing, and the client code has to un-necessarily 
> specify type parameters. For example, I have to write:
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> instead of
> StrLookup lookup = StrLookup.noneLookup();
> StrLookup lookup2 = StrLookup.systemPropertiesLookup();
> StrLookup lookup3 = StrLookup.mapLookup(integerMap);
> My best guess is that this type parameter was added when commons-lang was 
> generified, because StringLookup.mapLookup() takes a generified Map. Doing 
> this is not really needed, though: we could remove the  type parameter 
> everywhere, and replace the StrLookup.mapLookup()'s Map with a 
> Map (which is the same as Map, but 
> shorter).
> I guess it's too late to change this now, due to backward compatibility... 
> But I thought I'd comment just in case it's still possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1356) Add bypass option for classes to recursive and reflective EqualsBuilder

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1356.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.8

Patch applied. Thanks!

> Add bypass option for classes to recursive and reflective EqualsBuilder
> ---
>
> Key: LANG-1356
> URL: https://issues.apache.org/jira/browse/LANG-1356
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.reflect.*
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 3.8
>
> Attachments: LANG-1356.patch
>
>
> {quote}String are now compared with internal data (hash and char[]). But 
> sometimes hash value is not initialized, this is probably a cache for the 
> hashcode. So the comparison fails even if the char[] content is the same.
> You should add the bypass for basic JRE classes (String, Datetime types, 
> etc.){quote}
> reported at 
> https://github.com/apache/commons-lang/pull/202#issuecomment-333874925



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1356) Add bypass option for classes to recursive and reflective EqualsBuilder

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1356:

Summary: Add bypass option for classes to recursive and reflective 
EqualsBuilder  (was: Add bypass for basic JRE classes to recursive and 
reflective EqualsBuilder)

> Add bypass option for classes to recursive and reflective EqualsBuilder
> ---
>
> Key: LANG-1356
> URL: https://issues.apache.org/jira/browse/LANG-1356
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.reflect.*
>Reporter: Pascal Schumacher
>Priority: Major
> Attachments: LANG-1356.patch
>
>
> {quote}String are now compared with internal data (hash and char[]). But 
> sometimes hash value is not initialized, this is probably a cache for the 
> hashcode. So the comparison fails even if the char[] content is the same.
> You should add the bypass for basic JRE classes (String, Datetime types, 
> etc.){quote}
> reported at 
> https://github.com/apache/commons-lang/pull/202#issuecomment-333874925



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1364) ExceptionUtils#getRootCause(Throwable t) should return t if no lower level cause exists

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1364.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.8

> ExceptionUtils#getRootCause(Throwable t) should return t if no lower level 
> cause exists
> ---
>
> Key: LANG-1364
> URL: https://issues.apache.org/jira/browse/LANG-1364
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.6
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 3.8
>
>
> {quote}
> I have found the design of three root cause related methods inconsistent
> when the input Throwable does not wrap up another Throwable.
> These three methods are
>1. getRootCause(Throwable t)
>2. getRootCauseMessage(Throwable t)
>3. getRootCauseStackTrace(Throwable t)
> When the input t has no lower level cause:
>- the first method returns null;
>- the second method returns the message of t, which means the input t is
>considered as the root cause in this method;
>- the third method returns the stack trace of t, which also means this
>method considers t as the root cause.
> Therefore, I consider the design of the first method is not consistent with
> the second and the third.
> I usually write a function myself to get the root cause of an exception;
> and it makes much better sense to me the root cause of a Throwable is
> itself if no more lower level cause exists.
> A request: change the first method to return t itself when there is no more
> 'causes'.
> {quote}
> Reported by Zheng Xie in 
> https://mail-archives.apache.org/mod_mbox/commons-dev/201710.mbox/%3CCAL-LHk7jvQGM9J1SPxLB2qEsXazwwq%2BYKuv29XgWXEcccHUn0w%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1364) ExceptionUtils#getRootCause(Throwable t) should return t if no lower level cause exists

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1364:

Summary: ExceptionUtils#getRootCause(Throwable t) should return t if no 
lower level cause exists  (was: ExceptionUtils#getRootCause* inconsistency)

> ExceptionUtils#getRootCause(Throwable t) should return t if no lower level 
> cause exists
> ---
>
> Key: LANG-1364
> URL: https://issues.apache.org/jira/browse/LANG-1364
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.6
>Reporter: Pascal Schumacher
>Priority: Major
>
> {quote}
> I have found the design of three root cause related methods inconsistent
> when the input Throwable does not wrap up another Throwable.
> These three methods are
>1. getRootCause(Throwable t)
>2. getRootCauseMessage(Throwable t)
>3. getRootCauseStackTrace(Throwable t)
> When the input t has no lower level cause:
>- the first method returns null;
>- the second method returns the message of t, which means the input t is
>considered as the root cause in this method;
>- the third method returns the stack trace of t, which also means this
>method considers t as the root cause.
> Therefore, I consider the design of the first method is not consistent with
> the second and the third.
> I usually write a function myself to get the root cause of an exception;
> and it makes much better sense to me the root cause of a Throwable is
> itself if no more lower level cause exists.
> A request: change the first method to return t itself when there is no more
> 'causes'.
> {quote}
> Reported by Zheng Xie in 
> https://mail-archives.apache.org/mod_mbox/commons-dev/201710.mbox/%3CCAL-LHk7jvQGM9J1SPxLB2qEsXazwwq%2BYKuv29XgWXEcccHUn0w%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1060) NumberUtils.isNumber assumes number starting with Zero is octal

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1060.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher  (was: Rob Tompkins)
Fix Version/s: (was: 3.x)
   3.8

> NumberUtils.isNumber assumes number starting with Zero is octal
> ---
>
> Key: LANG-1060
> URL: https://issues.apache.org/jira/browse/LANG-1060
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 3.3.2
>Reporter: James Haugen
>Assignee: Pascal Schumacher
>Priority: Major
> Fix For: 3.8
>
>
> The isNumber method assumes, that if the String being passed in doesn't have 
> an 'X' at the second char it is an octal number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Moved] (TEXT-112) Conditional expansion (variation of default value syntax)

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher moved LANG-1378 to TEXT-112:
--

Fix Version/s: (was: 3.8)
Affects Version/s: (was: 3.7)
  Component/s: (was: lang.text.*)
 Workflow: jira  (was: Default workflow, editable Closed status)
  Key: TEXT-112  (was: LANG-1378)
  Project: Commons Text  (was: Commons Lang)

> Conditional expansion (variation of default value syntax)
> -
>
> Key: TEXT-112
> URL: https://issues.apache.org/jira/browse/TEXT-112
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Charles Fineman
>Priority: Major
>
> I'd like to propose an extension to the current syntax (and would consider 
> submitting a PR for it if folks are in favor of the proposal)
> There is currently support for: ${undefined.number:-1234567890}
> I'm proposing adding: ${defined.number:?The number is ${defined.number}}
> My quick glance of the recursive interpolation makes me feel this would be 
> relatively straightforward.
>  
> Curious when the next version would be released (I asked because I could 
> actually make use of this in something I'm working on right now)
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1378) Conditional expansion (variation of default value syntax)

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351726#comment-16351726
 ] 

Pascal Schumacher commented on LANG-1378:
-

Thanks for the proposal. 

I guess you are talking about StrSubstitutor? This class has been deprecated in 
version 3.6 and is now maintained as part of commons-text.

I will therefore move this issue to commons-text.

> Conditional expansion (variation of default value syntax)
> -
>
> Key: LANG-1378
> URL: https://issues.apache.org/jira/browse/LANG-1378
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.text.*
>Affects Versions: 3.7
>Reporter: Charles Fineman
>Priority: Major
> Fix For: 3.8
>
>
> I'd like to propose an extension to the current syntax (and would consider 
> submitting a PR for it if folks are in favor of the proposal)
> There is currently support for: ${undefined.number:-1234567890}
> I'm proposing adding: ${defined.number:?The number is ${defined.number}}
> My quick glance of the recursive interpolation makes me feel this would be 
> relatively straightforward.
>  
> Curious when the next version would be released (I asked because I could 
> actually make use of this in something I'm working on right now)
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IO-557) UnsupportedEncodingException when opening an ISO-8859-1 XML stream with Turkish as the default locale

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IO-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved IO-557.
--
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 2.7

> UnsupportedEncodingException when opening an ISO-8859-1 XML stream with 
> Turkish as the default locale
> -
>
> Key: IO-557
> URL: https://issues.apache.org/jira/browse/IO-557
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.6
> Environment: JVM running with argument -Duser.language=tr, or on an 
> Operating System with Turkish as its preferred language.
>Reporter: luccioman
>Assignee: Pascal Schumacher
>Priority: Minor
>  Labels: easyfix
> Fix For: 2.7
>
>
> When the default locale is set to the Turkish language, using the 
> XmlStreamReader constructor on an XML stream with a prolog including the 
> ISO-8859-1 charset name in lowercase as its encoding throws a 
> UnsupportedEncodingException (java.io.UnsupportedEncodingException: 
> İSO-8859-1).
> Example XML prolog : 
> This is apparently because the XmlStreamReader class uses 
> String.toUpperCase() in its getXmlProlog() function. It should rather use 
> toUpperCase(Locale.ROOT) or toUpperCase(Locale.US) as already done in the 
> getContentTypeEncoding() function. Otherwise the behaviour can be different 
> depending on the default locale, as the dotted lower case i becomes a dotted 
> upper case i in the Turkish language, which not the case with other languages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-111) WordUtils.wrap must calculate offset increment from wrapOn pattern length

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325393#comment-16325393
 ] 

Pascal Schumacher commented on TEXT-111:


Thanks for reporting this.

I gave the suggested fix a try, but it causes other tests to fail.

A pull request/patch would be greatly appreciated.

> WordUtils.wrap must calculate offset increment from wrapOn pattern length
> -
>
> Key: TEXT-111
> URL: https://issues.apache.org/jira/browse/TEXT-111
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Michael Keppler
>
> WordUtils.wrap(...) allows to specify the "wrapOn" regular expression to be 
> used as breakable characters. If this pattern is a zero width assertion or is 
> longer than 1 charachter, then the output is wrong because the wrapping 
> algorithm always skips one character (assuming the line break character has a 
> width of 1).
> Example failing test:
> {code:java}
> assertThat(WordUtils.wrap("abcdef", 2, "\n", false, 
> "(?=d)")).isEqualTo("abc\ndef");
> // produces "abc\nef" instead
> {code}
> Fix would be to change the 2 occurences of
> {code:java}
> offset = spaceToWrapAt + 1;
> {code}
> to
> {code:java}
> offset = spaceToWrapAt + matcher.end() - matcher.start();
> {code}
> thereby not advancing 1 character each time, but as many characters as were 
> just matched.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (TEXT-111) WordUtils.wrap must calculate offset increment from wrapOn pattern length

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325393#comment-16325393
 ] 

Pascal Schumacher edited comment on TEXT-111 at 1/14/18 12:32 AM:
--

Thanks for reporting this!

I gave the suggested fix a try, but it causes other tests to fail.

A pull request/patch would be greatly appreciated.


was (Author: pascalschumacher):
Thanks for reporting this.

I gave the suggested fix a try, but it causes other tests to fail.

A pull request/patch would be greatly appreciated.

> WordUtils.wrap must calculate offset increment from wrapOn pattern length
> -
>
> Key: TEXT-111
> URL: https://issues.apache.org/jira/browse/TEXT-111
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Michael Keppler
>
> WordUtils.wrap(...) allows to specify the "wrapOn" regular expression to be 
> used as breakable characters. If this pattern is a zero width assertion or is 
> longer than 1 charachter, then the output is wrong because the wrapping 
> algorithm always skips one character (assuming the line break character has a 
> width of 1).
> Example failing test:
> {code:java}
> assertThat(WordUtils.wrap("abcdef", 2, "\n", false, 
> "(?=d)")).isEqualTo("abc\ndef");
> // produces "abc\nef" instead
> {code}
> Fix would be to change the 2 occurences of
> {code:java}
> offset = spaceToWrapAt + 1;
> {code}
> to
> {code:java}
> offset = spaceToWrapAt + matcher.end() - matcher.start();
> {code}
> thereby not advancing 1 character each time, but as many characters as were 
> just matched.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LANG-1372) Add ToStringSummary annotation

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1372.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.8

> Add ToStringSummary annotation
> --
>
> Key: LANG-1372
> URL: https://issues.apache.org/jira/browse/LANG-1372
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Sérgio Ozaki
>Assignee: Pascal Schumacher
>Priority: Trivial
> Fix For: 3.8
>
>
> Add @ToStringSummary annotation for fields you may wish not to display full 
> description.
> It is useful for fields which are too large or contains sensitive 
> information. 
> https://github.com/apache/commons-lang/pull/281



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LANG-1352) EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1352.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.8

> EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added
> ---
>
> Key: LANG-1352
> URL: https://issues.apache.org/jira/browse/LANG-1352
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Ruslan Sibgatullin
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.8
>
>
> EnumUtils.getEnumIgnoreCase and isValidEnumIgnoreCase methods added.
> I truly believe that such handy method must exist in this utility class.
> [This|https://stackoverflow.com/questions/28332924/case-insensitive-matching-of-a-string-to-a-java-enum]
>  SO thread is just a prove of it. And also in the project I work for we need 
> to perform this operation quite often. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (EMAIL-176) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/EMAIL-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved EMAIL-176.
-
   Resolution: Fixed
Fix Version/s: 1.6

> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> -
>
> Key: EMAIL-176
> URL: https://issues.apache.org/jira/browse/EMAIL-176
> Project: Commons Email
>  Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.6
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (EMAIL-176) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

[Pascal Schumacher (JIRA)]

Pascal Schumacher created EMAIL-176:
---

 Summary: Add Automatic-Module-Name MANIFEST entry for Java 9 
compatibility
 Key: EMAIL-176
 URL: https://issues.apache.org/jira/browse/EMAIL-176
 Project: Commons Email
  Issue Type: New Feature
Reporter: Pascal Schumacher
Assignee: Pascal Schumacher






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (NET-648) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved NET-648.
---
   Resolution: Fixed
Fix Version/s: 3.7

> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> -
>
> Key: NET-648
> URL: https://issues.apache.org/jira/browse/NET-648
> Project: Commons Net
>  Issue Type: Improvement
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 3.7
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (NET-648) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

[Pascal Schumacher (JIRA)]

Pascal Schumacher created NET-648:
-

 Summary: Add Automatic-Module-Name MANIFEST entry for Java 9 
compatibility
 Key: NET-648
 URL: https://issues.apache.org/jira/browse/NET-648
 Project: Commons Net
  Issue Type: Improvement
Reporter: Pascal Schumacher
Assignee: Pascal Schumacher






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-110) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-110.

   Resolution: Fixed
Fix Version/s: 1.3

> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> -
>
> Key: TEXT-110
> URL: https://issues.apache.org/jira/browse/TEXT-110
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TEXT-110) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility

[Pascal Schumacher (JIRA)]

Pascal Schumacher created TEXT-110:
--

 Summary: Add Automatic-Module-Name MANIFEST entry for Java 9 
compatibility
 Key: TEXT-110
 URL: https://issues.apache.org/jira/browse/TEXT-110
 Project: Commons Text
  Issue Type: Improvement
Reporter: Pascal Schumacher
Assignee: Pascal Schumacher






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-70) Build failure with java 9-ea+159

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-70.
---
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: (was: 1.x)
   1.3

Resolved by updating to commons-parent version 43 which uses maven-site-plugin 
3.7.

> Build failure with java 9-ea+159
> 
>
> Key: TEXT-70
> URL: https://issues.apache.org/jira/browse/TEXT-70
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.0-beta-1
> Environment: $ mvn -X
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T11:41:47-05:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac"
>Reporter: Rob Tompkins
>Assignee: Pascal Schumacher
> Fix For: 1.3
>
>
> {{mvn -X clean site}} fails with the following error trace (noting that this 
> feels more like a bug with the maven-site-plugin than with our 
> code...regardless it's worth logging):
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project 
> commons-text: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on 
> project commons-text: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:547)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.6:site 
> failed: Unable to make private java.io.File(java.lang.String,java.io.File) 
> accessible: module java.base does not "opens java.io" to unnamed module 
> @47313e46
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   ... 20 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46
>   at 
> 

[jira] [Resolved] (LANG-1371) Fix TypeUtils#parameterize to work correctly with narrower-typed array

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1371.
-
   Resolution: Fixed
Fix Version/s: 3.8

> Fix TypeUtils#parameterize to work correctly with narrower-typed array
> --
>
> Key: LANG-1371
> URL: https://issues.apache.org/jira/browse/LANG-1371
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.7
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.8
>
>
> reported in [https://github.com/apache/commons-lang/pull/307]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LANG-1371) Fix TypeUtils#parameterize to work correctly with narrower-typed array

[Pascal Schumacher (JIRA)]

Pascal Schumacher created LANG-1371:
---

 Summary: Fix TypeUtils#parameterize to work correctly with 
narrower-typed array
 Key: LANG-1371
 URL: https://issues.apache.org/jira/browse/LANG-1371
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 3.7
Reporter: Pascal Schumacher
Assignee: Pascal Schumacher
Priority: Minor


reported in [https://github.com/apache/commons-lang/pull/307]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-92) Update commons-lang dependency to version 3.6

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-92.
-

> Update commons-lang dependency to version 3.6
> -
>
> Key: TEXT-92
> URL: https://issues.apache.org/jira/browse/TEXT-92
> Project: Commons Text
>  Issue Type: Task
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 1.2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-107) Upversion commons-lang to 3.7

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-107.
--

> Upversion commons-lang to 3.7
> -
>
> Key: TEXT-107
> URL: https://issues.apache.org/jira/browse/TEXT-107
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Trivial
> Fix For: 1.2
>
>
> Already done in git.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-100.
--

> StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
> ---
>
> Key: TEXT-100
> URL: https://issues.apache.org/jira/browse/TEXT-100
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Michael Hausegger
>Assignee: Bruno P. Kinoshita
> Fix For: 1.2
>
>
> As shown in 
> org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON 
> escape signs do not get treated correctly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-74.
-

> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
> Fix For: 1.2
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to 
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some 
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$". 
> This is annoying. Especially as I use one template with variables as a value 
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-89) WordUtils.initials support for UTF-16 surrogate pairs

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-89.
-

> WordUtils.initials support for UTF-16 surrogate pairs
> -
>
> Key: TEXT-89
> URL: https://issues.apache.org/jira/browse/TEXT-89
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Arun Vinud 
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 1.2
>
>
> The current implementation of WordUtils.initials() doesn't support UTF-32 . 
> Refactor the code to provide support using UTF-16 surrogate pairs  . The 
> proposed improvement should provide support to characters outside BMP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-85) Create CaseUtils class. Add toCamelCase

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-85.
-

> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> I wonder if we should think about deprecating the case management in 
> {{WordUtils}} and move it over? Maybe, maybe not.
> I would think our method signature would look something like:
> {code}
> String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
> {code}
> potentially with {{String}} replaced with {{CharSequence}}.
> Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
> might be a good starting point. 
> https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-88.
-

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-105) Typo in LongestCommonSubsequence#logestCommonSubsequence

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-105.
--

> Typo in LongestCommonSubsequence#logestCommonSubsequence
> 
>
> Key: TEXT-105
> URL: https://issues.apache.org/jira/browse/TEXT-105
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 1.2
>
>
> Reported by Abrasha in https://github.com/apache/commons-text/pull/69
> {quote}Also I found a typo in public signature in 
> org.apache.commons.text.similarity.LongestCommonSubsequence#logestCommonSubsequence{quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-91) RandomStringGenerator should be able to generate a String with a random length

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-91.
-

> RandomStringGenerator should be able to generate a String with a random length
> --
>
> Key: TEXT-91
> URL: https://issues.apache.org/jira/browse/TEXT-91
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-108) Publish snapshots to apache snapshot repository

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-108.
--

> Publish snapshots to apache snapshot repository
> ---
>
> Key: TEXT-108
> URL: https://issues.apache.org/jira/browse/TEXT-108
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Victor Romero
>
> I was looking forward to use the HumanNameParser but found out that 
> 1.3-SNAPSHOT is not being deployed into 
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-text/
>  even if the 1.3-SNAPSHOT site is already deployed to 
> https://commons.apache.org/proper/commons-text/index.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-97.
-

> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][]  ranges = {{'0','9'}};
> RandomStringGenerator generator = new 
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][]  ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new 
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][]  ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new 
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-67) NumericEntityUnescaper.options - fix TODO

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-67.
-

> NumericEntityUnescaper.options - fix TODO
> -
>
> Key: TEXT-67
> URL: https://issues.apache.org/jira/browse/TEXT-67
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
>Reporter: Rob Tompkins
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.2
>
>
> To mitigate having checkstyle errors, we have added this Jira en lieu of the 
> TODO comment in the code.
> Below the JavaDoc for the {{options}} private variable, but above the 
> variable reads:
> bq. Create an OptionsSet class to hide some of the conditional logic below



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-106.
--

> Exception thrown in ExtendedMessageFormat using quotes with custom registry
> ---
>
> Key: TEXT-106
> URL: https://issues.apache.org/jira/browse/TEXT-106
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Benoît Moreau
>Assignee: Bruno P. Kinoshita
> Fix For: 1.2
>
> Attachments: ExtendedMessageFormat.java.patch, 
> ExtendedMessageFormatTest.java.patch
>
>
> An exception is thrown when a quote is used just before end brace of format 
> element definition when a custom registry is used.
> This exception is not thrown when a blank space is added before the end brace.
> {code:java}
> public static void main(String[] args)
> {
>   String pattern   = "TEST: {0,choice,0#0|0<'1'}";
>   String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space 
> after quote
>   // Works fine
>   MessageFormat format0 = new MessageFormat(pattern);
>   System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern);
>   System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1"
>   // Works fine
>   ExtendedMessageFormat format2 = new 
> ExtendedMessageFormat(patternWorkaround, new HashMap FormatFactory>());
>   System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0"
>   System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 "
>   // Doesn't work
>   ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new 
> HashMap());
>   System.out.println(format3.format(new Integer[] { 0 })); // Exception 
> in thread "main" java.lang.IllegalArgumentException: Unterminated format 
> element at position 9
>   System.out.println(format3.format(new Integer[] { 1 }));
> }
> {code}
> Expected behavior: This exception should not be thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-90.
-

> Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic 
> numerals
> ---
>
> Key: TEXT-90
> URL: https://issues.apache.org/jira/browse/TEXT-90
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.2
>
>
> I tried to migrate a project from RandomStringUtils to RandomStringGenerator 
> today, but I found it hard to replace methods like 
> RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.
> I believe it would ease migration from RandomStringUtils to 
> RandomStringGenerator if CharacterPrecidates would offer more predicates.
> Edit:
> Added CharacterPredicates#ARABIC_NUMERALS, #ASCII_LOWERCASE_LETTERS, 
> #ASCII_UPPERCASE_LETTERS, #ASCII_LETTERS and #ASCII_ALPHA_NUMERALS.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-83) Document that commons-csv should be used in preference to CsvTranslators

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-83.
-

> Document that commons-csv should be used in preference to CsvTranslators
> 
>
> Key: TEXT-83
> URL: https://issues.apache.org/jira/browse/TEXT-83
> Project: Commons Text
>  Issue Type: Task
>Reporter: Amey Jadiye
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 1.2
>
>
> Document that commons-csv should be used in preference to CsvTranslators.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-93.
-

> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-98) Remove isDelimiter() and use HashSets for delimiter check

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-98.
-

> Remove isDelimiter() and use HashSets for delimiter check
> -
>
> Key: TEXT-98
> URL: https://issues.apache.org/jira/browse/TEXT-98
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Arun Vinud 
>Priority: Minor
> Fix For: 1.2
>
>
> The current implementation of *capitalize*, *uncapitalize* and *initials* in 
> *WordUtils* calls *isDelimiter* for every character and/or codepoint and 
> isDelimiter loops through the array of delimiters to check for the  
> occurrence. This is a bit inefficient and results in O(nk) complexity and it 
> can be reduced to O( n )[if n>k] or O( k ) [if k>n].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-88.
---
Resolution: Fixed

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-93.
---
Resolution: Fixed

> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher reopened TEXT-93:
---

> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-93:
--
Fix Version/s: 1.2

> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed TEXT-88.
-
Assignee: Rob Tompkins

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher reopened TEXT-88:
---

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-88:
--
Affects Version/s: 1.1

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.2
>
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-88:
--
Fix Version/s: 1.2

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Rob Tompkins
> Fix For: 1.2
>
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1349) EqualsBuilder#isRegistered: swappedPair construction bug

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1349.
---

> EqualsBuilder#isRegistered: swappedPair construction bug
> 
>
> Key: LANG-1349
> URL: https://issues.apache.org/jira/browse/LANG-1349
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.builder.*
>Affects Versions: 3.6
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 3.7
>
>
> See
> https://stackoverflow.com/questions/45603317/org-apache-commons-lang3-builder-equalsbuilder
> and
> https://github.com/apache/commons-lang/pull/282
> for details.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1350) ConstructorUtils.invokeConstructor(Class, Object...) regression

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1350.
---

> ConstructorUtils.invokeConstructor(Class, Object...) regression
> ---
>
> Key: LANG-1350
> URL: https://issues.apache.org/jira/browse/LANG-1350
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.reflect.*
>Affects Versions: 3.5, 3.6
>Reporter: Brett Kail
> Fix For: 3.7
>
>
> As of LANG-1115, the following test program no longer works:
> {noformat}
> public class ConstructorUtilsTest {
>   @Test
>   public void test() throws Exception {
>   ConstructorUtils.invokeConstructor(TestCtor.class, new A() {}, 
> new B[0]);
>   }
>   public static class TestCtor {
>   public TestCtor(A a, B... b) {}
>   }
>   public static class A {}
>   public static class B {}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1348) StackOverflowError on TypeUtils.toString(...) for a generic return type of Enum.valueOf

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1348.
---

> StackOverflowError on TypeUtils.toString(...) for a generic return type of 
> Enum.valueOf
> ---
>
> Key: LANG-1348
> URL: https://issues.apache.org/jira/browse/LANG-1348
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.reflect.*
>Affects Versions: 3.6
> Environment: Java 8 update 144
>Reporter: Dmitry Ovchinnikov
>Assignee: Pascal Schumacher
> Fix For: 3.7
>
>
> The following code
> {code:java}
> final Method method = Enum.class.getMethod("valueOf", Class.class, 
> String.class);
> final String typeText = TypeUtils.toString(method.getGenericReturnType());
> {code}
> throws the following
> {code:none}
> Exception in thread "main" java.lang.StackOverflowError
>   at 
> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.getRawType(ParameterizedTypeImpl.java:126)
>   at 
> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.getRawType(ParameterizedTypeImpl.java:40)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.parameterizedTypeToString(TypeUtils.java:1790)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1666)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.parameterizedTypeToString(TypeUtils.java:1803)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1666)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.parameterizedTypeToString(TypeUtils.java:1803)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1666)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.parameterizedTypeToString(TypeUtils.java:1803)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1666)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
>   at 
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1346) Remove deprecation from RandomStringUtils

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1346.
---

> Remove deprecation from RandomStringUtils
> -
>
> Key: LANG-1346
> URL: https://issues.apache.org/jira/browse/LANG-1346
> Project: Commons Lang
>  Issue Type: Task
>Affects Versions: 3.7
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 3.7
>
>
> As discussed on the mailing list, RandomStringUtils is easier to use (for 
> simple use cases) that commons-text RandomStringGenerator. Therefore we 
> should remove the deprecation.
> See 
> [https://mail-archives.apache.org/mod_mbox/commons-dev/201707.mbox/%3C6bb96beb-db2b-2ef0-3a0f-f3ceeec5d236%40gmx.net%3E]
>  for details.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1358) Improve StringUtils#replace throughput

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1358.
---

> 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)

[jira] [Closed] (LANG-1361) ExceptionUtils.getThrowableList() is using deprecated ExceptionUtils.getCause()

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1361.
---

> ExceptionUtils.getThrowableList() is using deprecated 
> ExceptionUtils.getCause()
> ---
>
> Key: LANG-1361
> URL: https://issues.apache.org/jira/browse/LANG-1361
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.exception.*
>Affects Versions: 3.6
>Reporter: Ana
> Fix For: 3.7
>
>
> Though ExceptionUtils.getCause is deprecated it's used internally, for 
> example in ExceptionUtils.getThrowables. 
> We noticed this while running performance tests where a large number of 
> NoSuchMethod exceptions where seen since ExceptionUtils.getCause catches them 
> repeatedly. Unless initialised carefully, creating exceptions has the 
> overhead of filling the stack trace which was our performance concern. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1355.
---

> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
> Fix For: 3.7
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1360) Add methods to ClassUtils to get various forms of class names in a null-safe manner

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1360.
---

> Add methods to ClassUtils to get various forms of class names in a null-safe 
> manner
> ---
>
> Key: LANG-1360
> URL: https://issues.apache.org/jira/browse/LANG-1360
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 3.7
>
>
> Fill out methods ClassUtils to get various forms of class names in a 
> null-safe manner:
> - getName(Class)
> - getName(Object)
> - getName(Class, String)
> - getName(Object, String)
> - getSimpleName(Class)
> - getSimpleName(Object)
> - getSimpleName(Class, String)
> - getSimpleName(Object, String)
> - getCanonicalName(Class)
> - getCanonicalName(Object)
> - getCanonicalName(Class, String)
> - getCanonicalName(Object, String)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher closed LANG-1362.
---

> Fix tests DateUtilsTest for Java 9 with en_GB locale
> 
>
> Key: LANG-1362
> URL: https://issues.apache.org/jira/browse/LANG-1362
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Reporter: Stephen Colebourne
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 3.7
>
>
> On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not 
> formatted as "MST". I'm unclear as to why this is, but it is not relevant to 
> what the test is trying to do. As such, I've changed the zone to 
> "America/Denver" and changed the format letter from "z" to "XXX" to make it 
> more reliable.
> The PR also uses try-finally when setting the default time-zone to avoid 
> pollution of global state if a test fails (the pollution here made it look 
> like 8 test failures when there was only in fact 1).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1362.
-
Resolution: Fixed
  Assignee: Gary Gregory

> Fix tests DateUtilsTest for Java 9 with en_GB locale
> 
>
> Key: LANG-1362
> URL: https://issues.apache.org/jira/browse/LANG-1362
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Reporter: Stephen Colebourne
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 3.7
>
>
> On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not 
> formatted as "MST". I'm unclear as to why this is, but it is not relevant to 
> what the test is trying to do. As such, I've changed the zone to 
> "America/Denver" and changed the format letter from "z" to "XXX" to make it 
> more reliable.
> The PR also uses try-finally when setting the default time-zone to avoid 
> pollution of global state if a test fails (the pollution here made it look 
> like 8 test failures when there was only in fact 1).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1362:

   Priority: Minor  (was: Major)
Component/s: lang.time.*

> Fix tests DateUtilsTest for Java 9 with en_GB locale
> 
>
> Key: LANG-1362
> URL: https://issues.apache.org/jira/browse/LANG-1362
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Reporter: Stephen Colebourne
>Priority: Minor
> Fix For: 3.7
>
>
> On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not 
> formatted as "MST". I'm unclear as to why this is, but it is not relevant to 
> what the test is trying to do. As such, I've changed the zone to 
> "America/Denver" and changed the format letter from "z" to "XXX" to make it 
> more reliable.
> The PR also uses try-finally when setting the default time-zone to avoid 
> pollution of global state if a test fails (the pollution here made it look 
> like 8 test failures when there was only in fact 1).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-94) Add Damerau option to Levenshtein edit distance

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223711#comment-16223711
 ] 

Pascal Schumacher commented on TEXT-94:
---

[~arohit] I am obviously not Rob, but Rob has not committed a solution for this 
in over two months, so I guess he is not currently working on it and you are 
welcome to give it a try.

> Add Damerau option to Levenshtein edit distance
> ---
>
> Key: TEXT-94
> URL: https://issues.apache.org/jira/browse/TEXT-94
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Ulf Dittmer
>Assignee: Rob Tompkins
>Priority: Minor
>
> Please add support for transpositions of two characters as defined by the 
> Levenshtein-Damerau edit distance: 
> https://en.wikipedia.org/wiki/Damerau%E2%80%93Levenshtein_distance
> It's not hard to implement, and some code for it can be found as part of 
> https://issues.apache.org/jira/browse/LUCENE-3662



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LANG-1364) ExceptionUtils#getRootCause* inconsistency

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1364:

Affects Version/s: 3.6

> ExceptionUtils#getRootCause* inconsistency
> --
>
> Key: LANG-1364
> URL: https://issues.apache.org/jira/browse/LANG-1364
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.6
>Reporter: Pascal Schumacher
>
> {quote}
> I have found the design of three root cause related methods inconsistent
> when the input Throwable does not wrap up another Throwable.
> These three methods are
>1. getRootCause(Throwable t)
>2. getRootCauseMessage(Throwable t)
>3. getRootCauseStackTrace(Throwable t)
> When the input t has no lower level cause:
>- the first method returns null;
>- the second method returns the message of t, which means the input t is
>considered as the root cause in this method;
>- the third method returns the stack trace of t, which also means this
>method considers t as the root cause.
> Therefore, I consider the design of the first method is not consistent with
> the second and the third.
> I usually write a function myself to get the root cause of an exception;
> and it makes much better sense to me the root cause of a Throwable is
> itself if no more lower level cause exists.
> A request: change the first method to return t itself when there is no more
> 'causes'.
> {quote}
> Reported by Zheng Xie in 
> https://mail-archives.apache.org/mod_mbox/commons-dev/201710.mbox/%3CCAL-LHk7jvQGM9J1SPxLB2qEsXazwwq%2BYKuv29XgWXEcccHUn0w%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LANG-1364) ExceptionUtils#getRootCause* inconsistency

[Pascal Schumacher (JIRA)]

Pascal Schumacher created LANG-1364:
---

 Summary: ExceptionUtils#getRootCause* inconsistency
 Key: LANG-1364
 URL: https://issues.apache.org/jira/browse/LANG-1364
 Project: Commons Lang
  Issue Type: Bug
Reporter: Pascal Schumacher


{quote}
I have found the design of three root cause related methods inconsistent
when the input Throwable does not wrap up another Throwable.

These three methods are

   1. getRootCause(Throwable t)
   2. getRootCauseMessage(Throwable t)
   3. getRootCauseStackTrace(Throwable t)


When the input t has no lower level cause:

   - the first method returns null;
   - the second method returns the message of t, which means the input t is
   considered as the root cause in this method;
   - the third method returns the stack trace of t, which also means this
   method considers t as the root cause.

Therefore, I consider the design of the first method is not consistent with
the second and the third.

I usually write a function myself to get the root cause of an exception;
and it makes much better sense to me the root cause of a Throwable is
itself if no more lower level cause exists.

A request: change the first method to return t itself when there is no more
'causes'.
{quote}

Reported by Zheng Xie in 
https://mail-archives.apache.org/mod_mbox/commons-dev/201710.mbox/%3CCAL-LHk7jvQGM9J1SPxLB2qEsXazwwq%2BYKuv29XgWXEcccHUn0w%40mail.gmail.com%3E




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223696#comment-16223696
 ] 

Pascal Schumacher commented on LANG-1362:
-

To replicated add {code}-Duser.country=GB -Duser.language=en{code} to surefire 
argLine.

> Fix tests DateUtilsTest for Java 9 with en_GB locale
> 
>
> Key: LANG-1362
> URL: https://issues.apache.org/jira/browse/LANG-1362
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Stephen Colebourne
> Fix For: 3.7
>
>
> On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not 
> formatted as "MST". I'm unclear as to why this is, but it is not relevant to 
> what the test is trying to do. As such, I've changed the zone to 
> "America/Denver" and changed the format letter from "z" to "XXX" to make it 
> more reliable.
> The PR also uses try-finally when setting the default time-zone to avoid 
> pollution of global state if a test fails (the pollution here made it look 
> like 8 test failures when there was only in fact 1).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1362:

Summary: Fix tests DateUtilsTest for Java 9 with en_GB locale  (was: Fix 
tests for Java 9)

> Fix tests DateUtilsTest for Java 9 with en_GB locale
> 
>
> Key: LANG-1362
> URL: https://issues.apache.org/jira/browse/LANG-1362
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Stephen Colebourne
> Fix For: 3.7
>
>
> On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not 
> formatted as "MST". I'm unclear as to why this is, but it is not relevant to 
> what the test is trying to do. As such, I've changed the zone to 
> "America/Denver" and changed the format letter from "z" to "XXX" to make it 
> more reliable.
> The PR also uses try-finally when setting the default time-zone to avoid 
> pollution of global state if a test fails (the pollution here made it look 
> like 8 test failures when there was only in fact 1).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COLLECTIONS-662) Build failures when building with Java 9

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212851#comment-16212851
 ] 

Pascal Schumacher commented on COLLECTIONS-662:
---

Yes. Thanks for resolving the issue and adding the changes.xml entry. I forgot 
to do that. :( Sorry.

> 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
>Assignee: Pascal Schumacher
>
> *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] (TEXT-103) Add provision to change the cost for insert, delete and replace operation in levenshtein distance

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212824#comment-16212824
 ] 

Pascal Schumacher commented on TEXT-103:


[~arohit] Consider this issue assigned to you anyway. Looking forward to the 
pull request/patch. Thanks in advance! (Sadly it is not possible to assign 
issues to people who are not part of the commons developer group in jira, so it 
has to stay unassigned in jira.)

> Add provision to change the cost for insert, delete and replace operation in 
> levenshtein distance
> -
>
> Key: TEXT-103
> URL: https://issues.apache.org/jira/browse/TEXT-103
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rohit Agarwal
>Priority: Minor
>  Labels: newbie, patch
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> There are two implementation of levenshtein distance, unlimitedCompare and 
> limitedCompare.
> I propose to generalise the levenshtein distance by adding an option to 
> change the value of
> 1) Addition of Character.
> 2) Deletion of Character.
> 3) Substitution of Character.
> Currently they are all set to 1. For backward compatibility this will be the 
> default case.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-105) Typo in LongestCommonSubsequence#logestCommonSubsequence

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-105.

   Resolution: Fixed
Fix Version/s: 1.2

> Typo in LongestCommonSubsequence#logestCommonSubsequence
> 
>
> Key: TEXT-105
> URL: https://issues.apache.org/jira/browse/TEXT-105
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 1.2
>
>
> Reported by Abrasha in https://github.com/apache/commons-text/pull/69
> {quote}Also I found a typo in public signature in 
> org.apache.commons.text.similarity.LongestCommonSubsequence#logestCommonSubsequence{quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TEXT-105) Typo in LongestCommonSubsequence#logestCommonSubsequence

[Pascal Schumacher (JIRA)]

Pascal Schumacher created TEXT-105:
--

 Summary: Typo in LongestCommonSubsequence#logestCommonSubsequence
 Key: TEXT-105
 URL: https://issues.apache.org/jira/browse/TEXT-105
 Project: Commons Text
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Pascal Schumacher
Assignee: Pascal Schumacher
Priority: Minor


Reported by Abrasha in https://github.com/apache/commons-text/pull/69

{quote}Also I found a typo in public signature in 
org.apache.commons.text.similarity.LongestCommonSubsequence#logestCommonSubsequence{quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IO-526) The problem of log acquisition

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IO-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated IO-526:
-
Fix Version/s: (was: 2.5)

> The problem of log acquisition
> --
>
> Key: IO-526
> URL: https://issues.apache.org/jira/browse/IO-526
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.5
>Reporter: 张华
>
> Problem Description:
> Recently a problem appeared in the use of commons io 2.5 when Tailer 
> class is in the process of monitoring and reading log files: there is lost 
> logs and repeatedly collected logs for the collection of log files 
> continuously split by time .
> Scene reproduction:
>   We use log4j-1.2.17 in our project to generate the log file and split 
> it up once every hour. If the current file name is system.log, the file name 
> after splitting is system1.log.The Tailer class in commons io 2.5 monitors 
> changes to the file every 500 milliseconds.
>  1. The current system.log length is 10, position is also 10, after 
> cutting the new system.log length is 20, then this.length is greater than 
> position and position is set to 0, the old file collection then repeats (ie, 
> system1. Log). New log is missing.
>  2. The current system.log length is 10,position is 10, after cutting new 
> system.log length is 10, then this.length is equal to position, no log 
> information is read. New file logs is missing.
> I hope commons io team can solve this problem, thank you!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IO-546) ClosedOutputStream#flush should throw

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IO-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved IO-546.
--
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 2.6

> ClosedOutputStream#flush should throw
> -
>
> Key: IO-546
> URL: https://issues.apache.org/jira/browse/IO-546
> Project: Commons IO
>  Issue Type: Improvement
>  Components: Streams/Writers
>Reporter: Tomas Celaya
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.6
>
> Attachments: IO-546.patch
>
>
> While debugging an issue involving usage of {{CloseShieldOutputStream}} I 
> discovered that {{ClosedOutputStream#flush}} is not overridden and will 
> silently succeed. Not sure how much of a breaking change this might be but I 
> think it makes more sense for {{ClosedOutputStream#flush}} to throw. This is 
> only really meaningful in contexts where multiple streams are being chained 
> together and some of the streams before {{CloseShieldOutputStream}} perform 
> buffering, but it would make behavior more consistent for these more complex 
> use-cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-99) Performance Degradation for Escaping JSON

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203785#comment-16203785
 ] 

Pascal Schumacher commented on TEXT-99:
---

Thanks for reporting!

I could not find any difference in the implementations that seemed to be the 
cause of this regression, so I have no idea how to fix it.

I sadly lack knowledge in this area, so I won't be able to implement the  
suggested `java.io.write(char cbuf[], int off, int len)` change.

Pull requests welcome!

> Performance Degradation for Escaping JSON
> -
>
> Key: TEXT-99
> URL: https://issues.apache.org/jira/browse/TEXT-99
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: OS X 10.11.6
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> JProfiler 9.1 (Build 9128)
>Reporter: Tom Howard
>Priority: Minor
>  Labels: escape, json, performance
>
> There seams to be a small performance degradation on 
> StringEscapeUtils.escapeJson(String) in commons-text v1.1 compared to 
> commons-lang3 v3.5
> I have a performance test that involves (amongst other things) escaping 
> 200,052 strings. Using commons-text v1.1 this consistently takes 100ms to 
> 110ms. Using commons-lang3 v3.5 this consistently takes 92ms to 95ms.
> Also, after escaping I'm writing it to using java.io.Writer.write(String). I 
> would have assumed that StringEscapeUtils.ESCAPE_JSON.translate(CharSequence, 
> writer) would yield better performance, however in the same test, using this 
> method constantly takes approx 210ms and the parent method (which serialises 
> the entire payload to JSON) takes approx 1750ms compared to approx 1400ms 
> using StringEscapeUtils.escapeJson(String) from commons-lang3 v3.5
> I've marked the issue as minor, as it doesn't really impact me, but I thought 
> I should share my findings.
> The serialiser can be found at 
> https://github.com/mountain-pass/ryvr/blob/master/src/main/java/au/com/mountainpass/ryvr/io/RyvrSerialiser.java
>  and the performance test can be executed using `./gradlew 
> testRyvrTests_Integration_Performance_Java_H2Local`
> Also, I should mention that StringEscapeUtils.escapeJson is an order of 
> magnitude faster than the equivalents from:
> - org.json:json:20170516
> - org.unbescape:unbescape:1.1.5.RELEASE
> - com.googlecode.json-simple:1.1.1
> - net.minidev:son-smart:2.3
> They literally take over 1000ms to do what StringEscapeUtils.escapeJson() 
> does in about 100ms. If there are any other libs you would like me to test 
> against for comparison purposes, please let me know.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-70) Build failure with java 9-ea+159

[Pascal Schumacher (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203722#comment-16203722
 ] 

Pascal Schumacher commented on TEXT-70:
---

We have to wait for the release of the maven-site-plugin version 3.7 which will 
included https://issues.apache.org/jira/browse/MSITE-796 which is the maven 
site failure on java 9 mention above (29/8/17).

> Build failure with java 9-ea+159
> 
>
> Key: TEXT-70
> URL: https://issues.apache.org/jira/browse/TEXT-70
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.0-beta-1
> Environment: $ mvn -X
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T11:41:47-05:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac"
>Reporter: Rob Tompkins
> Fix For: 1.x
>
>
> {{mvn -X clean site}} fails with the following error trace (noting that this 
> feels more like a bug with the maven-site-plugin than with our 
> code...regardless it's worth logging):
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project 
> commons-text: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on 
> project commons-text: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:547)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.6:site 
> failed: Unable to make private java.io.File(java.lang.String,java.io.File) 
> accessible: module java.base does not "opens java.io" to unnamed module 
> @47313e46
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   ... 20 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46
>   at 
> 

[jira] [Updated] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated TEXT-100:
---
Affects Version/s: 1.1

> StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
> ---
>
> Key: TEXT-100
> URL: https://issues.apache.org/jira/browse/TEXT-100
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Michael Hausegger
>
> As shown in 
> org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON 
> escape signs do not get treated correctly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

[Pascal Schumacher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved TEXT-74.
---
   Resolution: Fixed
 Assignee: Rob Tompkins
Fix Version/s: (was: 1.x)
   1.2

> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
> Fix For: 1.2
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to 
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some 
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$". 
> This is annoying. Especially as I use one template with variables as a value 
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)