[jira] [Commented] (BCEL-289) Crash when parsing constructor of inner classes with parameters annotated

2017-05-19 Thread Bruno P. Kinoshita (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16018180#comment-16018180
 ] 

Bruno P. Kinoshita commented on BCEL-289:
-

+1 that would be great :-)

> Crash when parsing constructor of inner classes with parameters annotated
> -
>
> Key: BCEL-289
> URL: https://issues.apache.org/jira/browse/BCEL-289
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 6.0
>Reporter: Pietro Ferrara
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Fix For: 6.1
>
>
> BCEL crashes when parsing the constructor of an inner class whose parameters 
> are annotated. For instance, when parsing the jar obtained from the following 
> classes:
> {code:java}
> public @interface A {}
> public @interface B {}
> public class Test {
> public class Inner {
>   public Inner(@A Object a, @B Object b) {}
> }
> }
> {code}
> In particular:
> {code:java}
>   ClassParser cp = new ClassParser(args[0]);
>   ClassGen cg = new ClassGen(cp.parse());
>   MethodGen mg = new MethodGen(cg.getMethodAt(0), 
> cg.getClassName(), cg.getConstantPool());
>   mg.getAnnotationsOnParameter(0);
> {code}
> (where args\[0\] points to Test$Inner.class)
> you get
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
>   at 
> org.apache.bcel.generic.MethodGen.ensureExistingParameterAnnotationsUnpacked(MethodGen.java:1120)
>   at 
> org.apache.bcel.generic.MethodGen.getAnnotationsOnParameter(MethodGen.java:1073)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COLLECTIONS-602) Improve efficiency of DefaultedMap.get

2017-05-19 Thread Bruno P. Kinoshita (JIRA) 

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

Bruno P. Kinoshita commented on COLLECTIONS-602:


Sounds like a good argument [~jmark]. Would you be interested in submitting a 
pull request? :-)

> Improve efficiency of DefaultedMap.get
> --
>
> Key: COLLECTIONS-602
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-602
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: John Mark
>  Labels: help-wanted
>
> The current implementation of 
> {{org.apache.commons.collections4.map.DefaultedMap.get()}} is inefficient 
> since it always require two map lookups. There is no need to check 
> map.containsKey() every time. I would suggest implementing this method 
> similar to the way that Java 8 does with {{Map.getOrDefault()}}. My proposed 
> implementation would be something like this:
> {code}
> public V get(final Object key) {
> V v;
> return ((v = map.get(key) != null) || map.containsKey(key)) ? v : 
> value.transform((K) key);
> }
> {code}
> It can be further optimized to not even call map.containsKey() if map is 
> known to not contain null values.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (COLLECTIONS-602) Improve efficiency of DefaultedMap.get

2017-05-19 Thread Bruno P. Kinoshita (JIRA) 

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

Bruno P. Kinoshita updated COLLECTIONS-602:
---
Labels: help-wanted  (was: )

> Improve efficiency of DefaultedMap.get
> --
>
> Key: COLLECTIONS-602
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-602
> Project: Commons Collections
>  Issue Type: Bug
>Reporter: John Mark
>  Labels: help-wanted
>
> The current implementation of 
> {{org.apache.commons.collections4.map.DefaultedMap.get()}} is inefficient 
> since it always require two map lookups. There is no need to check 
> map.containsKey() every time. I would suggest implementing this method 
> similar to the way that Java 8 does with {{Map.getOrDefault()}}. My proposed 
> implementation would be something like this:
> {code}
> public V get(final Object key) {
> V v;
> return ((v = map.get(key) != null) || map.containsKey(key)) ? v : 
> value.transform((K) key);
> }
> {code}
> It can be further optimized to not even call map.containsKey() if map is 
> known to not contain null values.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (LANG-1319) MultilineRecursiveToStringStyle StackOverflowError when object is an array

2017-05-19 Thread Duncan Jones (JIRA) 

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

Duncan Jones closed LANG-1319.
--
   Resolution: Fixed
Fix Version/s: 3.6

Thanks for the report. Fixed in commit 7587431.

> MultilineRecursiveToStringStyle StackOverflowError when object is an array 
> ---
>
> Key: LANG-1319
> URL: https://issues.apache.org/jira/browse/LANG-1319
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.builder.*
>Affects Versions: 3.5
>Reporter: Sergiy Proskuryakov
>Assignee: Duncan Jones
> Fix For: 3.6
>
>
> MultilineRecursiveToStringStyle style = new MultilineRecursiveToStringStyle();
> String result = ToStringBuilder.reflectionToString(new String[] {"1","2"}, 
> style);
> java.lang.StackOverflowError
>   at 
> org.apache.commons.lang3.builder.ToStringStyle.appendStart(ToStringStyle.java:409)
>   at 
> org.apache.commons.lang3.builder.ToStringBuilder.(ToStringBuilder.java:262)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.(ReflectionToStringBuilder.java:481)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:300)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:157)
>   at 
> org.apache.commons.lang3.builder.RecursiveToStringStyle.appendDetail(RecursiveToStringStyle.java:74)
>   at 
> org.apache.commons.lang3.builder.MultilineRecursiveToStringStyle.reflectionAppendArrayDetail(MultilineRecursiveToStringStyle.java:142)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.reflectionAppendArray(ReflectionToStringBuilder.java:633)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:538)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:711)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:301)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:157)
>   at 
> org.apache.commons.lang3.builder.RecursiveToStringStyle.appendDetail(RecursiveToStringStyle.java:74)
>   at 
> org.apache.commons.lang3.builder.MultilineRecursiveToStringStyle.reflectionAppendArrayDetail(MultilineRecursiveToStringStyle.java:142)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (LANG-1319) MultilineRecursiveToStringStyle StackOverflowError when object is an array

2017-05-19 Thread Duncan Jones (JIRA) 

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

Duncan Jones updated LANG-1319:
---
Assignee: Duncan Jones

> MultilineRecursiveToStringStyle StackOverflowError when object is an array 
> ---
>
> Key: LANG-1319
> URL: https://issues.apache.org/jira/browse/LANG-1319
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.builder.*
>Affects Versions: 3.5
>Reporter: Sergiy Proskuryakov
>Assignee: Duncan Jones
>
> MultilineRecursiveToStringStyle style = new MultilineRecursiveToStringStyle();
> String result = ToStringBuilder.reflectionToString(new String[] {"1","2"}, 
> style);
> java.lang.StackOverflowError
>   at 
> org.apache.commons.lang3.builder.ToStringStyle.appendStart(ToStringStyle.java:409)
>   at 
> org.apache.commons.lang3.builder.ToStringBuilder.(ToStringBuilder.java:262)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.(ReflectionToStringBuilder.java:481)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:300)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:157)
>   at 
> org.apache.commons.lang3.builder.RecursiveToStringStyle.appendDetail(RecursiveToStringStyle.java:74)
>   at 
> org.apache.commons.lang3.builder.MultilineRecursiveToStringStyle.reflectionAppendArrayDetail(MultilineRecursiveToStringStyle.java:142)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.reflectionAppendArray(ReflectionToStringBuilder.java:633)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:538)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:711)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:301)
>   at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:157)
>   at 
> org.apache.commons.lang3.builder.RecursiveToStringStyle.appendDetail(RecursiveToStringStyle.java:74)
>   at 
> org.apache.commons.lang3.builder.MultilineRecursiveToStringStyle.reflectionAppendArrayDetail(MultilineRecursiveToStringStyle.java:142)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-19 Thread Gary Gregory (JIRA) 

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

Gary Gregory commented on TEXT-25:
--

I agree with @britter, this feels out of scope.

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.x
>
>
> 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
(v6.3.15#6346)

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

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins commented on TEXT-25:
--

I think that was similar to the point that Benedikt was trying to make here: 
https://github.com/apache/commons-text/pull/24

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.x
>
>
> 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
(v6.3.15#6346)

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

2017-05-19 Thread Gary Gregory (JIRA) 

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

Gary Gregory commented on TEXT-25:
--

We should make it clear that this is an alternative solution to using the ISO 
8601 format strings with Java 8 or Joda-Time which give you all the level of 
granularity you need.

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.x
>
>
> 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
(v6.3.15#6346)

[jira] [Updated] (TEXT-73) Add Properties support to StrLookup

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-73:
-
Fix Version/s: 1.x

> Add Properties support to StrLookup
> ---
>
> Key: TEXT-73
> URL: https://issues.apache.org/jira/browse/TEXT-73
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Anthony Whitford
>Priority: Minor
> Fix For: 1.x
>
> Attachments: StrLookup.patch, StrLookup.patch
>
>
> Sadly, 
> [Properties|http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html]
>  implements {{Map}} instead of {{Map}}, so one 
> can not use the {{MapStrLookup}}.
> I propose adding a Properties variant.  Patch attached.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-25:
-
Fix Version/s: (was: 1.1)
   1.x

> 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
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.x
>
>
> 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
(v6.3.15#6346)

[jira] [Updated] (TEXT-44) NumericEntityUnescaper.translate throws an IllegalArgumentException if entityValue > MAX_CODE_POINT

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-44:
-
Fix Version/s: (was: 1.1)
   1.x

> NumericEntityUnescaper.translate throws an IllegalArgumentException if 
> entityValue > MAX_CODE_POINT
> ---
>
> Key: TEXT-44
> URL: https://issues.apache.org/jira/browse/TEXT-44
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Miquel
>Priority: Minor
> Fix For: 1.x
>
>
> We found that using the function StringEscapeUtils.unescapeHtml4 crashes if 
> the argument is "" and throws an IllegalArgumentException.
> This happens because internally it calls the function 
> NumericEntityUnescaper.translate and doesn't check if the value is bigger 
> than 0x10 (MAX_CODE_POINT) that is a check inside Character.toChar.
> Maybe we need to check that the entity value is less than Char.MAX_CODE_POINT.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (TEXT-46) StringEscapeUtils.unescapeHtml: handle HTML escapes without semicolon

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-46:
-
Fix Version/s: (was: 1.1)
   1.x

> StringEscapeUtils.unescapeHtml: handle HTML escapes without semicolon
> -
>
> Key: TEXT-46
> URL: https://issues.apache.org/jira/browse/TEXT-46
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Steve Hale
>Priority: Minor
> Fix For: 1.x
>
> Attachments: commons-lang3-LANG-757.patch
>
>
> org.apache.commons.lang.StringEscapeUtils.unescapeHtml is useful in detecting 
> and correcting Cross-Site Scripting (XSS) attempts by converting escaped 
> chars like

[jira] [Updated] (TEXT-43) [XSS] StringEscapeUtils.escapeHtml() must escape ' chars to

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-43:
-
Fix Version/s: (was: 1.1)
   1.x

> [XSS] StringEscapeUtils.escapeHtml() must escape ' chars to  
> --
>
> Key: TEXT-43
> URL: https://issues.apache.org/jira/browse/TEXT-43
> Project: Commons Text
>  Issue Type: Improvement
> Environment: Operating System: All
> Platform: All 
>Reporter: Keisuke Kato
>Priority: Minor
> Fix For: 1.x
>
>
> If developers putting untrusted data into attribute values using the single 
> quote character ' and StringEscapeUtils.escapeHtml() like:
>  value=*'<%=StringEscapeUtils.escapeHtml(request.getParameter("input"))%>'*>
> Then, the attacker is able to break out of the HTML attribute context like:
> hxxp://example.org/?input=*' onfocus='alert(document.cookie);' id='*
>  value='*'onfocus='alert(document.cookie);'id='*'>
> I think [LANG\-122|https://issues.apache.org/jira/browse/LANG-122] is not 
> truly fixed from this aspect (XSS).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-74:
-
Fix Version/s: 1.x

> 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
>Priority: Minor
>  Labels: features
> Fix For: 1.x
>
>
> In StrSubstitutor variable replacement works in a recursive way. 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 replacemnt 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 "Hello world". The 
> commented line is my suggestion for this feature. If it works, it should 
> print "Hello ${key2}":
> Map valueMap = new HashMap<>();
> valueMap.put("key", "$${key2}");
> valueMap.put("key2", "world");
> String source = "Hello ${key}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (TEXT-48) StringEscapeUtils.unescapeEcmaScript: No hexadecimal nor octal encoding supported

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-48:
-
Fix Version/s: (was: 1.1)
   1.x

> StringEscapeUtils.unescapeEcmaScript: No hexadecimal nor octal encoding 
> supported
> -
>
> Key: TEXT-48
> URL: https://issues.apache.org/jira/browse/TEXT-48
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Jan Peter Stotz
>  Labels: escaping
> Fix For: 1.x
>
>
> I encountered several JavaScript/EcmaScript strings that use octal or 
> hexadecimal encoded characters -  e.g. \042 or \x22 
> The only supported encoding variant is "unicode encoding" using "\u" as 
> prefix. 
> I tried to unescape them using StringEscapeUtils.unescapeEcmaScript() however 
> that fails as both encodings are not supported (which is not mentioned).
> I searched the net a bit and found the following information:
> Octal encoding is still used around the net but has been removed in EC5: 
> https://mathiasbynens.be/notes/javascript-escapes#octal
> Hexadecimal escape sequences however seems to be still allowed in EC5 and EC6:
> https://mathiasbynens.be/notes/javascript-escapes#hexadecimal



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (TEXT-75) StrTokenizer needs to support access to the token separators

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-75:
-
Fix Version/s: 1.x

> StrTokenizer needs to support access to the token separators
> 
>
> Key: TEXT-75
> URL: https://issues.apache.org/jira/browse/TEXT-75
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Stephen Colebourne
>Priority: Minor
> Fix For: 1.x
>
>
> With StrTokenizer at present you cannot extract the separators between the 
> tokens, a feature which is possible with StringTokenizer.
> Thus tokenizing "a.b@c.d" using ".@" would return a,b,c,d but you wouldn't 
> know where the @ was.
> This could probably best be part of the API as a lastSeparator() method that 
> can only be called after next(), returning the separator(s) between that 
> token and the previous token.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (TEXT-77) Add code to check if a given string is a palindrome

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-77:
-
Fix Version/s: 1.x

> Add code to check if a given string is a palindrome
> ---
>
> Key: TEXT-77
> URL: https://issues.apache.org/jira/browse/TEXT-77
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>  Labels: easy, help-wanted, text
> Fix For: 1.x
>
>
> I had a look at 
> [lang|https://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html]
>  and 
> [text|https://commons.apache.org/proper/commons-text/javadocs/api-release/index.html]
>  API's, but could not locate a class/method for 
> [palindromes|https://en.wikipedia.org/wiki/Palindrome].
> Ideally, it would support words or sentences such as "racecar" and "step on 
> no pets".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (TEXT-79) Investigate adding string search algorithms

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-79:
-
Fix Version/s: 1.x

> Investigate adding string search algorithms
> ---
>
> Key: TEXT-79
> URL: https://issues.apache.org/jira/browse/TEXT-79
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>  Labels: algorithm, help-wanted, text
> Fix For: 1.x
>
>
> There are a few [string searching 
> algorithms|https://en.wikipedia.org/wiki/String_searching_algorithm] (e.g. 
> Rabin Karp) that do not have an implementation in commons yet.
> Would be interesting to check if any other ASF projects use any of these or 
> others (e.g. Lucene, Solr, Tika, etc) and see if they could be implemented in 
> [text].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-19 Thread Rob Tompkins (JIRA) 

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

Rob Tompkins updated TEXT-80:
-
Fix Version/s: 1.x

> StrLookup API confusing
> ---
>
> Key: TEXT-80
> URL: https://issues.apache.org/jira/browse/TEXT-80
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Etienne Neveu
> Fix For: 1.x
>
>
> [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
(v6.3.15#6346)

[jira] [Commented] (BCEL-289) Crash when parsing constructor of inner classes with parameters annotated

2017-05-19 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16017559#comment-16017559
 ] 

Gary Gregory commented on BCEL-289:
---

Time to migrate to Git then?

> Crash when parsing constructor of inner classes with parameters annotated
> -
>
> Key: BCEL-289
> URL: https://issues.apache.org/jira/browse/BCEL-289
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 6.0
>Reporter: Pietro Ferrara
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Fix For: 6.1
>
>
> BCEL crashes when parsing the constructor of an inner class whose parameters 
> are annotated. For instance, when parsing the jar obtained from the following 
> classes:
> {code:java}
> public @interface A {}
> public @interface B {}
> public class Test {
> public class Inner {
>   public Inner(@A Object a, @B Object b) {}
> }
> }
> {code}
> In particular:
> {code:java}
>   ClassParser cp = new ClassParser(args[0]);
>   ClassGen cg = new ClassGen(cp.parse());
>   MethodGen mg = new MethodGen(cg.getMethodAt(0), 
> cg.getClassName(), cg.getConstantPool());
>   mg.getAnnotationsOnParameter(0);
> {code}
> (where args\[0\] points to Test$Inner.class)
> you get
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
>   at 
> org.apache.bcel.generic.MethodGen.ensureExistingParameterAnnotationsUnpacked(MethodGen.java:1120)
>   at 
> org.apache.bcel.generic.MethodGen.getAnnotationsOnParameter(MethodGen.java:1073)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (COLLECTIONS-602) Improve efficiency of DefaultedMap.get

2017-05-19 Thread John Mark (JIRA) 
John Mark created COLLECTIONS-602:
-

 Summary: Improve efficiency of DefaultedMap.get
 Key: COLLECTIONS-602
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-602
 Project: Commons Collections
  Issue Type: Bug
Reporter: John Mark


The current implementation of 
{{org.apache.commons.collections4.map.DefaultedMap.get()}} is inefficient since 
it always require two map lookups. There is no need to check map.containsKey() 
every time. I would suggest implementing this method similar to the way that 
Java 8 does with {{Map.getOrDefault()}}. My proposed implementation would be 
something like this:

{code}
public V get(final Object key) {
V v;
return ((v = map.get(key) != null) || map.containsKey(key)) ? v : 
value.transform((K) key);
}
{code}

It can be further optimized to not even call map.containsKey() if map is known 
to not contain null values.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (VFS-634) DefaultFileSystemManager.close() throw FileSystemException

2017-05-19 Thread Dominique Jean-Prost (JIRA) 

[ 
https://issues.apache.org/jira/browse/VFS-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16017100#comment-16017100
 ] 

Dominique Jean-Prost commented on VFS-634:
--

Hello [~b.eckenfels],

I work with [~GilianHalouin]. Is there a piece of information I should give to 
you so that it can help you to diagnose ? Thank you.

> DefaultFileSystemManager.close() throw FileSystemException
> --
>
> Key: VFS-634
> URL: https://issues.apache.org/jira/browse/VFS-634
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: windows
>Reporter: Gilian HALOUIN
>
> Hi,
> We face an issue when we use the DefaultFileSystemManager.
> With this example :
> {code:java}
> import org.apache.commons.vfs2.FileObject;
> import org.apache.commons.vfs2.FileSystemException;
> import org.apache.commons.vfs2.Selectors;
> import org.apache.commons.vfs2.VFS;
> import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
> /**
>  * @author GHALOUIN
>  *
>  */
> public class TestVFS {
> /**
>  * @param args
>  * @throws FileSystemException
>  */
> public static void main(final String[] args) throws FileSystemException {
> final DefaultFileSystemManager vfsManager = 
> (DefaultFileSystemManager) VFS.getManager();
> final FileObject tempDir = vfsManager.resolveFile("tmp://simulation");
> final FileObject fileSrc = vfsManager.resolveFile("C:/toto.txt");
> tempDir.resolveFile("toto").copyFrom(fileSrc, Selectors.SELECT_SELF);
> vfsManager.close();
> }
> }
> {code}
> At the close call we have the following error :
> INFOS: Using "C:\Users\ghalouin\AppData\Local\Temp\vfs_cache" as temporary 
> files store.
> avr. 21, 2017 4:21:27 PM 
> org.apache.commons.vfs2.impl.StandardFileSystemManager warn
> AVERTISSEMENT: Could not clean up temporary file "tmp_382_tempfs".
> org.apache.commons.vfs2.FileSystemException: Incorrect file system URI 
> "file:///C:/" in name 
> "file:///C:/Users/ghalouin/AppData/Local/Temp/vfs_cache/tmp_382_tempfs", was 
> expecting "file:///C:".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:324)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:317)
>   at 
> org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:84)
>   at 
> org.apache.commons.vfs2.provider.local.DefaultLocalFileProvider.findLocalFile(DefaultLocalFileProvider.java:106)
>   at 
> org.apache.commons.vfs2.provider.local.DefaultLocalFileProvider.findLocalFile(DefaultLocalFileProvider.java:119)
>   at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.toFileObject(DefaultFileSystemManager.java:1003)
>   at 
> org.apache.commons.vfs2.impl.DefaultVfsComponentContext.toFileObject(DefaultVfsComponentContext.java:78)
>   at 
> org.apache.commons.vfs2.impl.DefaultFileReplicator.deleteFile(DefaultFileReplicator.java:172)
>   at 
> org.apache.commons.vfs2.impl.DefaultFileReplicator.close(DefaultFileReplicator.java:111)
>   at 
> org.apache.commons.vfs2.impl.PrivilegedFileReplicator$CloseAction.run(PrivilegedFileReplicator.java:195)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.commons.vfs2.impl.PrivilegedFileReplicator.close(PrivilegedFileReplicator.java:113)
>   at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.closeComponent(DefaultFileSystemManager.java:500)
>   at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.close(DefaultFileSystemManager.java:604)
>   at testVFS.TestVFS.main(TestVFS.java:29)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (BCEL-289) Crash when parsing constructor of inner classes with parameters annotated

2017-05-19 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16016977#comment-16016977
 ] 

ASF GitHub Bot commented on BCEL-289:
-

Github user asfgit closed the pull request at:

https://github.com/apache/commons-bcel/pull/13


> Crash when parsing constructor of inner classes with parameters annotated
> -
>
> Key: BCEL-289
> URL: https://issues.apache.org/jira/browse/BCEL-289
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 6.0
>Reporter: Pietro Ferrara
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Fix For: 6.1
>
>
> BCEL crashes when parsing the constructor of an inner class whose parameters 
> are annotated. For instance, when parsing the jar obtained from the following 
> classes:
> {code:java}
> public @interface A {}
> public @interface B {}
> public class Test {
> public class Inner {
>   public Inner(@A Object a, @B Object b) {}
> }
> }
> {code}
> In particular:
> {code:java}
>   ClassParser cp = new ClassParser(args[0]);
>   ClassGen cg = new ClassGen(cp.parse());
>   MethodGen mg = new MethodGen(cg.getMethodAt(0), 
> cg.getClassName(), cg.getConstantPool());
>   mg.getAnnotationsOnParameter(0);
> {code}
> (where args\[0\] points to Test$Inner.class)
> you get
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
>   at 
> org.apache.bcel.generic.MethodGen.ensureExistingParameterAnnotationsUnpacked(MethodGen.java:1120)
>   at 
> org.apache.bcel.generic.MethodGen.getAnnotationsOnParameter(MethodGen.java:1073)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (BCEL-289) Crash when parsing constructor of inner classes with parameters annotated

2017-05-19 Thread Bruno P. Kinoshita (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16016975#comment-16016975
 ] 

Bruno P. Kinoshita commented on BCEL-289:
-

Pull request merged in Subversion. The sync process takes a while normally, so 
we may have to wait minutes/hours till it is marked as closed in GitHub, and 
the ASF bot comments here. Should be included in BCEL 6.1.

Thanks!
Bruno

> Crash when parsing constructor of inner classes with parameters annotated
> -
>
> Key: BCEL-289
> URL: https://issues.apache.org/jira/browse/BCEL-289
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 6.0
>Reporter: Pietro Ferrara
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Fix For: 6.1
>
>
> BCEL crashes when parsing the constructor of an inner class whose parameters 
> are annotated. For instance, when parsing the jar obtained from the following 
> classes:
> {code:java}
> public @interface A {}
> public @interface B {}
> public class Test {
> public class Inner {
>   public Inner(@A Object a, @B Object b) {}
> }
> }
> {code}
> In particular:
> {code:java}
>   ClassParser cp = new ClassParser(args[0]);
>   ClassGen cg = new ClassGen(cp.parse());
>   MethodGen mg = new MethodGen(cg.getMethodAt(0), 
> cg.getClassName(), cg.getConstantPool());
>   mg.getAnnotationsOnParameter(0);
> {code}
> (where args\[0\] points to Test$Inner.class)
> you get
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
>   at 
> org.apache.bcel.generic.MethodGen.ensureExistingParameterAnnotationsUnpacked(MethodGen.java:1120)
>   at 
> org.apache.bcel.generic.MethodGen.getAnnotationsOnParameter(MethodGen.java:1073)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (BCEL-289) Crash when parsing constructor of inner classes with parameters annotated

2017-05-19 Thread Bruno P. Kinoshita (JIRA) 

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

Bruno P. Kinoshita resolved BCEL-289.
-
Resolution: Fixed

> Crash when parsing constructor of inner classes with parameters annotated
> -
>
> Key: BCEL-289
> URL: https://issues.apache.org/jira/browse/BCEL-289
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 6.0
>Reporter: Pietro Ferrara
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Fix For: 6.1
>
>
> BCEL crashes when parsing the constructor of an inner class whose parameters 
> are annotated. For instance, when parsing the jar obtained from the following 
> classes:
> {code:java}
> public @interface A {}
> public @interface B {}
> public class Test {
> public class Inner {
>   public Inner(@A Object a, @B Object b) {}
> }
> }
> {code}
> In particular:
> {code:java}
>   ClassParser cp = new ClassParser(args[0]);
>   ClassGen cg = new ClassGen(cp.parse());
>   MethodGen mg = new MethodGen(cg.getMethodAt(0), 
> cg.getClassName(), cg.getConstantPool());
>   mg.getAnnotationsOnParameter(0);
> {code}
> (where args\[0\] points to Test$Inner.class)
> you get
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
>   at 
> org.apache.bcel.generic.MethodGen.ensureExistingParameterAnnotationsUnpacked(MethodGen.java:1120)
>   at 
> org.apache.bcel.generic.MethodGen.getAnnotationsOnParameter(MethodGen.java:1073)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (BCEL-289) Crash when parsing constructor of inner classes with parameters annotated

2017-05-19 Thread Bruno P. Kinoshita (JIRA) 

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

Bruno P. Kinoshita updated BCEL-289:

Assignee: Bruno P. Kinoshita

> Crash when parsing constructor of inner classes with parameters annotated
> -
>
> Key: BCEL-289
> URL: https://issues.apache.org/jira/browse/BCEL-289
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: 6.0
>Reporter: Pietro Ferrara
>Assignee: Bruno P. Kinoshita
>Priority: Critical
> Fix For: 6.1
>
>
> BCEL crashes when parsing the constructor of an inner class whose parameters 
> are annotated. For instance, when parsing the jar obtained from the following 
> classes:
> {code:java}
> public @interface A {}
> public @interface B {}
> public class Test {
> public class Inner {
>   public Inner(@A Object a, @B Object b) {}
> }
> }
> {code}
> In particular:
> {code:java}
>   ClassParser cp = new ClassParser(args[0]);
>   ClassGen cg = new ClassGen(cp.parse());
>   MethodGen mg = new MethodGen(cg.getMethodAt(0), 
> cg.getClassName(), cg.getConstantPool());
>   mg.getAnnotationsOnParameter(0);
> {code}
> (where args\[0\] points to Test$Inner.class)
> you get
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2
>   at 
> org.apache.bcel.generic.MethodGen.ensureExistingParameterAnnotationsUnpacked(MethodGen.java:1120)
>   at 
> org.apache.bcel.generic.MethodGen.getAnnotationsOnParameter(MethodGen.java:1073)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)