[jira] [Commented] (CONFIGURATION-815) Package depends on log4j 1.2.17
[ https://issues.apache.org/jira/browse/CONFIGURATION-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17559278#comment-17559278 ] Henri Yandell commented on CONFIGURATION-815: - Digging in a bit There is this test file: [https://github.com/apache/commons-configuration/blob/master/src/test/java/org/apache/commons/configuration2/interpol/TestExprLookup.java] Seems to be testing Configuration's use in log4j 1.x. And also this Logging.java file: [https://github.com/apache/commons-configuration/blob/master/src/test/java/org/apache/commons/configuration2/Logging.java] This is setting up logging for tests in general. I don't see a lot of logging going on in src/test though; a lot of work seems to be done to set things up but the tests themselves don't seem to log. > Package depends on log4j 1.2.17 > --- > > Key: CONFIGURATION-815 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-815 > Project: Commons Configuration > Issue Type: Task >Reporter: Henri Yandell >Priority: Major > > Commons Configuration has a test dependency on log4j 1.2.17. As log4j 1.x is > EOL; it feels like that should be updated/replaced. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CONFIGURATION-815) Package depends on log4j 1.2.17
[ https://issues.apache.org/jira/browse/CONFIGURATION-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558991#comment-17558991 ] Henri Yandell commented on CONFIGURATION-815: - As in remove the test? or the logging in the test? Having the build bring in EOL'd software feels like something to avoid to me; but I recognize I'm not an active Commons (or even Java) developer so I'm probably missing context. > Package depends on log4j 1.2.17 > --- > > Key: CONFIGURATION-815 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-815 > Project: Commons Configuration > Issue Type: Task >Reporter: Henri Yandell >Priority: Major > > Commons Configuration has a test dependency on log4j 1.2.17. As log4j 1.x is > EOL; it feels like that should be updated/replaced. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CONFIGURATION-815) Package depends on log4j 1.2.17
Henri Yandell created CONFIGURATION-815: --- Summary: Package depends on log4j 1.2.17 Key: CONFIGURATION-815 URL: https://issues.apache.org/jira/browse/CONFIGURATION-815 Project: Commons Configuration Issue Type: Task Reporter: Henri Yandell Commons Configuration has a test dependency on log4j 1.2.17. As log4j 1.x is EOL; it feels like that should be updated/replaced. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (LANG-1208) StrSubstitutor can preserve escapes
[ https://issues.apache.org/jira/browse/LANG-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-1208. --- Resolution: Fixed Applied. > StrSubstitutor can preserve escapes > --- > > Key: LANG-1208 > URL: https://issues.apache.org/jira/browse/LANG-1208 > Project: Commons Lang > Issue Type: Improvement > Components: lang.text.* >Reporter: Henri Yandell > Fix For: 3.5 > > > Placeholder for https://github.com/apache/commons-lang/pull/124 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1208) StrSubstitutor can preserve escapes
Henri Yandell created LANG-1208: --- Summary: StrSubstitutor can preserve escapes Key: LANG-1208 URL: https://issues.apache.org/jira/browse/LANG-1208 Project: Commons Lang Issue Type: Improvement Components: lang.text.* Reporter: Henri Yandell Fix For: 3.5 Placeholder for https://github.com/apache/commons-lang/pull/124 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (LANG-1175) Remove Ant-based build
[
https://issues.apache.org/jira/browse/LANG-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-1175.
---
Resolution: Fixed
Applied.
> Remove Ant-based build
> --
>
> Key: LANG-1175
> URL: https://issues.apache.org/jira/browse/LANG-1175
> Project: Commons Lang
> Issue Type: Task
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Sergio Fernández
>Priority: Trivial
> Labels: ant
> Fix For: 3.5
>
>
> We still have a {{build.xml}} file in our source code, and [~britter] asked
> if we could remove it. The single case could be for helping the Debian Java
> Packaging Team. We
> [asked|https://lists.debian.org/debian-java/2015/10/msg00082.html] and Debian
> has already moved to Maven for Commons Lang 3.x packaging, so it should be
> safe to get rid of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1143) StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/LANG-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-1143: Fix Version/s: Review Patch > StringUtils should use toXxxxCase(int) rather than toXxxxCase(char) > --- > > Key: LANG-1143 > URL: https://issues.apache.org/jira/browse/LANG-1143 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Sebb > Fix For: Review Patch, 3.5 > > Attachments: LANG-1143.patch > > > The Javadoc for Character#toTitleCase(char) recommends using > Character#toTitleCase(int) instead. This method was added in Java 1.5 which > is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-903) Add XML implementation of ToStringStyle
[ https://issues.apache.org/jira/browse/LANG-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-903: --- Fix Version/s: (was: Patch Needed) Review Patch > Add XML implementation of ToStringStyle > --- > > Key: LANG-903 > URL: https://issues.apache.org/jira/browse/LANG-903 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Affects Versions: 3.1 >Reporter: Dave Hughes >Priority: Minor > Fix For: Review Patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Lang 1.1 included a commented out implementation of XMLToStringStyle. This > disappeared in later versions, but is a very useful implementation. > (JSONToStringStyle would also be very nice) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1120) StringUtils.stripAccents from "Ł" and "ł"
[
https://issues.apache.org/jira/browse/LANG-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-1120:
Fix Version/s: (was: Patch Needed)
Review Patch
> StringUtils.stripAccents from "Ł" and "ł"
> -
>
> Key: LANG-1120
> URL: https://issues.apache.org/jira/browse/LANG-1120
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
> Environment: win
>Reporter: Krzysztof Walczewski
> Fix For: Review Patch
>
>
> {code}
> import org.apache.commons.lang3.StringUtils;
> public class Main {
> public static void main(String[] args) {
> System.out.println(StringUtils.stripAccents("ĄŁÓŚŻŹĆŃ ąłóśżźćń"));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1034) Recursive and reflective equals builder
[
https://issues.apache.org/jira/browse/LANG-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-1034:
Fix Version/s: (was: Patch Needed)
Review Patch
> Recursive and reflective equals builder
> ---
>
> Key: LANG-1034
> URL: https://issues.apache.org/jira/browse/LANG-1034
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: Review Patch
>
> Attachments: LANG-1034.1.patch
>
>
> The current implementation of {{EqualsBuilder.reflectionEquals()}} uses
> object equality to test reference fields found in the class. It may be
> helpful to offer a method that recursively builds {{.equals()}} methods for
> each field and uses that to perform the comparison.
> This functionality could be further extended by accepting a list of classes
> to include/exclude. Classes that are excluded would use the normal object
> equality.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1181) MultilineRecursiveToStringStyle is not public
[ https://issues.apache.org/jira/browse/LANG-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-1181. --- Resolution: Duplicate > MultilineRecursiveToStringStyle is not public > - > > Key: LANG-1181 > URL: https://issues.apache.org/jira/browse/LANG-1181 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.4 >Reporter: Jeff Guinness >Priority: Minor > > The public access modifier is missing from the > MultilineRecursiveToStringStyle class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1143) StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/LANG-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14639758#comment-14639758 ] Henri Yandell commented on LANG-1143: - Same style of change needs to be applied to uncapitalize and I guess to swapCase (though I wonder how useful swapCase really is as a function). Note javadoc also needs changing for capitalize as it refers to toTitleCase(char). StringUtils should use toXxxxCase(int) rather than toXxxxCase(char) --- Key: LANG-1143 URL: https://issues.apache.org/jira/browse/LANG-1143 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Sebb Fix For: 3.5 Attachments: LANG-1143.patch The Javadoc for Character#toTitleCase(char) recommends using Character#toTitleCase(int) instead. This method was added in Java 1.5 which is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1142) StringUtils#capitalize: Javadoc says toTitleCase; code uses toUpperCase
[ https://issues.apache.org/jira/browse/LANG-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632726#comment-14632726 ] Henri Yandell commented on LANG-1142: - It definitely should use toTitleCase. I wonder when that changed. :( Looks like it was changed in http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringUtils.java?r1=1673944r2=1673943pathrev=1673944 - https://issues.apache.org/jira/browse/LANG-1058 - which fortunately is unreleased. StringUtils#capitalize: Javadoc says toTitleCase; code uses toUpperCase --- Key: LANG-1142 URL: https://issues.apache.org/jira/browse/LANG-1142 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.4 Reporter: Sebb The capitalize Javadoc says the code uses Character#toTitleCase, however the code actually uses Character#toUpperCase. Generally these produce the same result, but some charsets may have different characters for upper and title case - see for example the Javadoc [1] for Character#isTitleCase. The way I read this, the character that looks like lj is lower-case, LJ is upper case and Lj is title case - i.e. not the same. The question here is: should the code be corrected to use TitleCase or should the Javadoc be corrected to use UpperCase? [1] http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isTitleCase%28char%29 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1143) StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/LANG-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632739#comment-14632739 ] Henri Yandell commented on LANG-1143: - Seems fair. Started to poke on this, but means we need a getCodePoints(int, int, int[], int) to replace getChars(int, int, char[], int). Which appears to be in Java 8 (CharSequence.codepoints();IntStream). StringUtils should use toXxxxCase(int) rather than toXxxxCase(char) --- Key: LANG-1143 URL: https://issues.apache.org/jira/browse/LANG-1143 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Sebb The Javadoc for String#toTitleCase(char) recommends using String#toTitleCase(int) instead. This method was added in Java 1.5 which is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LANG-1010) StringEscapeUtils escapeXml escapes already escaped characters
[ https://issues.apache.org/jira/browse/LANG-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632742#comment-14632742 ] Henri Yandell edited comment on LANG-1010 at 7/19/15 9:01 AM: -- Thinking out loud, you could create a custom translator (subclass of CharSequenceTranslator). If the letter was an , you would look ahead to determine if it was a valid escaped character. If so you would write them out and return the size of what you wrote. Then you would create an AggregateTranslator around your custom translator and StringEscapeUtils.ESCAPE_XML11. was (Author: bayard): Thinking out loud, you could create a customer translator (subclass of CharSequenceTranslator). If the letter was an , you would look ahead to determine if it was a valid escaped character. If so you would write them out and return the size of what you wrote. Then you would create an AggregateTranslator around your custom translator and StringEscapeUtils.ESCAPE_XML11. StringEscapeUtils escapeXml escapes already escaped characters -- Key: LANG-1010 URL: https://issues.apache.org/jira/browse/LANG-1010 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.3 Reporter: Kaushal Kumar StringEscapeUtils escapeXml escapes already escaped characters. Is there a way to enhance this API to check if the character is not escaped only then escape the character. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1010) StringEscapeUtils escapeXml escapes already escaped characters
[ https://issues.apache.org/jira/browse/LANG-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632742#comment-14632742 ] Henri Yandell commented on LANG-1010: - Thinking out loud, you could create a customer translator (subclass of CharSequenceTranslator). If the letter was an , you would look ahead to determine if it was a valid escaped character. If so you would write them out and return the size of what you wrote. Then you would create an AggregateTranslator around your custom translator and StringEscapeUtils.ESCAPE_XML11. StringEscapeUtils escapeXml escapes already escaped characters -- Key: LANG-1010 URL: https://issues.apache.org/jira/browse/LANG-1010 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.3 Reporter: Kaushal Kumar StringEscapeUtils escapeXml escapes already escaped characters. Is there a way to enhance this API to check if the character is not escaped only then escape the character. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (LANG-1142) StringUtils#capitalize: Javadoc says toTitleCase; code uses toUpperCase
[ https://issues.apache.org/jira/browse/LANG-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-1142. --- Resolution: Fixed Fix Version/s: 3.5 $ git commit [master 421db38] Switched capitalize back to using toTitleCase. Added a test for this using the 'Lj' letter. LANG-1142 2 files changed, 4 insertions(+), 1 deletion(-) StringUtils#capitalize: Javadoc says toTitleCase; code uses toUpperCase --- Key: LANG-1142 URL: https://issues.apache.org/jira/browse/LANG-1142 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.4 Reporter: Sebb Fix For: 3.5 The capitalize Javadoc says the code uses Character#toTitleCase, however the code actually uses Character#toUpperCase. Generally these produce the same result, but some charsets may have different characters for upper and title case - see for example the Javadoc [1] for Character#isTitleCase. The way I read this, the character that looks like lj is lower-case, LJ is upper case and Lj is title case - i.e. not the same. The question here is: should the code be corrected to use TitleCase or should the Javadoc be corrected to use UpperCase? [1] http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isTitleCase%28char%29 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1010) StringEscapeUtils escapeXml escapes already escaped characters
[ https://issues.apache.org/jira/browse/LANG-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632857#comment-14632857 ] Henri Yandell commented on LANG-1010: - A bit sloppy, but I was thinking of something akin to not escaping an when it forms the start of one of /[a-zA-Z0-9]*;/ and /#[0-9]*;/ Agreed that the caller should typically provide unescaped Strings. StringEscapeUtils escapeXml escapes already escaped characters -- Key: LANG-1010 URL: https://issues.apache.org/jira/browse/LANG-1010 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.3 Reporter: Kaushal Kumar StringEscapeUtils escapeXml escapes already escaped characters. Is there a way to enhance this API to check if the character is not escaped only then escape the character. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1138) add a static method to create a started stopwatch
[ https://issues.apache.org/jira/browse/LANG-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell resolved LANG-1138. - Resolution: Fixed Fix Version/s: 3.5 $ git commit -m Adding a createStarted() method per request in LANG-1138 . [master 17a6d16] Adding a createStarted() method per request in LANG-1138 2 files changed, 21 insertions(+), 1 deletion(-) add a static method to create a started stopwatch - Key: LANG-1138 URL: https://issues.apache.org/jira/browse/LANG-1138 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Reporter: Walter Zhang Priority: Trivial Fix For: 3.5 Basically, I very next step after I new a stopwatch is starting it. Why don't we add a static method to get a started stopwatch. Save our strength. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1010) StringEscapeUtils escapeXml escapes already escaped characters
[ https://issues.apache.org/jira/browse/LANG-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell resolved LANG-1010. - Resolution: Won't Fix Resolving as Won't Fix. StringEscapeUtils escapeXml escapes already escaped characters -- Key: LANG-1010 URL: https://issues.apache.org/jira/browse/LANG-1010 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.3 Reporter: Kaushal Kumar StringEscapeUtils escapeXml escapes already escaped characters. Is there a way to enhance this API to check if the character is not escaped only then escape the character. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LANG-1010) StringEscapeUtils escapeXml escapes already escaped characters
[
https://issues.apache.org/jira/browse/LANG-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632857#comment-14632857
]
Henri Yandell edited comment on LANG-1010 at 7/19/15 4:14 PM:
--
A bit sloppy, but I was thinking of something akin to not escaping an when it
forms the start of one of: {noformat}/[a-zA-Z0-9]*;/ and /#[0-9]*;/{noformat}
Agreed that the caller should typically provide unescaped Strings.
was (Author: bayard):
A bit sloppy, but I was thinking of something akin to not escaping an when it
forms the start of one of: {noformat}/[a-zA-Z0-9]*;/ and /#[0-9]\*;/{noformat}
Agreed that the caller should typically provide unescaped Strings.
StringEscapeUtils escapeXml escapes already escaped characters
--
Key: LANG-1010
URL: https://issues.apache.org/jira/browse/LANG-1010
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 3.3
Reporter: Kaushal Kumar
StringEscapeUtils escapeXml escapes already escaped characters.
Is there a way to enhance this API to check if the character is not escaped
only then escape the character.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-1010) StringEscapeUtils escapeXml escapes already escaped characters
[
https://issues.apache.org/jira/browse/LANG-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632857#comment-14632857
]
Henri Yandell edited comment on LANG-1010 at 7/19/15 4:13 PM:
--
A bit sloppy, but I was thinking of something akin to not escaping an when it
forms the start of one of: {noformat}/[a-zA-Z0-9]*;/ and /#[0-9]\*;/{noformat}
Agreed that the caller should typically provide unescaped Strings.
was (Author: bayard):
A bit sloppy, but I was thinking of something akin to not escaping an when it
forms the start of one of /[a-zA-Z0-9]*;/ and /#[0-9]*;/
Agreed that the caller should typically provide unescaped Strings.
StringEscapeUtils escapeXml escapes already escaped characters
--
Key: LANG-1010
URL: https://issues.apache.org/jira/browse/LANG-1010
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 3.3
Reporter: Kaushal Kumar
StringEscapeUtils escapeXml escapes already escaped characters.
Is there a way to enhance this API to check if the character is not escaped
only then escape the character.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1143) StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/LANG-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-1143: Fix Version/s: 3.5 StringUtils should use toXxxxCase(int) rather than toXxxxCase(char) --- Key: LANG-1143 URL: https://issues.apache.org/jira/browse/LANG-1143 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Sebb Fix For: 3.5 Attachments: LANG-1143.patch The Javadoc for Character#toTitleCase(char) recommends using Character#toTitleCase(int) instead. This method was added in Java 1.5 which is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1143) StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/LANG-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632867#comment-14632867 ] Henri Yandell commented on LANG-1143: - Looks good to me. Passes tests. StringUtils should use toXxxxCase(int) rather than toXxxxCase(char) --- Key: LANG-1143 URL: https://issues.apache.org/jira/browse/LANG-1143 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Sebb Fix For: 3.5 Attachments: LANG-1143.patch The Javadoc for Character#toTitleCase(char) recommends using Character#toTitleCase(int) instead. This method was added in Java 1.5 which is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (LANG-1129) Remove svn keywords
[
https://issues.apache.org/jira/browse/LANG-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-1129.
---
Resolution: Fixed
Fix Version/s: (was: Patch Needed)
Done.
Remove svn keywords
---
Key: LANG-1129
URL: https://issues.apache.org/jira/browse/LANG-1129
Project: Commons Lang
Issue Type: Task
Reporter: Benedikt Ritter
Fix For: 3.5
After the git migration all our java files still reference the svn id keyword:
{code}
* @versions $Id$
{code}
We should drop this from the JavaDocs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1092) Wrong formating of time zones with daylight saving time in FastDatePrinter
[
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14361649#comment-14361649
]
Henri Yandell commented on LANG-1092:
-
Thank you Benedikt :)
Wrong formating of time zones with daylight saving time in FastDatePrinter
--
Key: LANG-1092
URL: https://issues.apache.org/jira/browse/LANG-1092
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.3.2
Reporter: Henri Yandell
Assignee: Benedikt Ritter
Fix For: 3.4
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when
the test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens
on every timezone, you will hit timezones that fail. e.g.:
{code}
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java (revision 1665715)
+++ FastDatePrinterTest.java (working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine
[
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359792#comment-14359792
]
Henri Yandell commented on LANG-1092:
-
I hear you, I winced when I saw the build was failing in the time package.
My improvement is merely one that makes the test 'work', and fail for everyone.
I think we should remove the time package from 3.4, putting it in its own
'legacy' jar :)
Unit Test failing due to timezone order on JVM/machine
--
Key: LANG-1092
URL: https://issues.apache.org/jira/browse/LANG-1092
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.3.2
Reporter: Henri Yandell
Fix For: Review Patch, 3.4
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when
the test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens
on every timezone, you will hit timezones that fail. e.g.:
{code}
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java (revision 1665715)
+++ FastDatePrinterTest.java (working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1092) Unit Test failing due to timezone order on JVM/machine
Henri Yandell created LANG-1092:
---
Summary: Unit Test failing due to timezone order on JVM/machine
Key: LANG-1092
URL: https://issues.apache.org/jira/browse/LANG-1092
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.3.2
Reporter: Henri Yandell
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when the
test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens on
every timezone, you will hit timezones that fail. e.g.:
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java(revision 1665715)
+++ FastDatePrinterTest.java(working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1092) Unit Test failing due to timezone order on JVM/machine
[
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-1092:
Description:
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when the
test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens on
every timezone, you will hit timezones that fail. e.g.:
{code}
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java(revision 1665715)
+++ FastDatePrinterTest.java(working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
{code}
was:
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when the
test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens on
every timezone, you will hit timezones that fail. e.g.:
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java(revision 1665715)
+++ FastDatePrinterTest.java(working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
Unit Test failing due to timezone order on JVM/machine
--
Key: LANG-1092
URL: https://issues.apache.org/jira/browse/LANG-1092
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.3.2
Reporter: Henri Yandell
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when
the test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens
on every timezone, you will hit timezones that fail. e.g.:
{code}
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java (revision 1665715)
+++ FastDatePrinterTest.java (working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1030) StringUtils.same opposite method to StringUtils.differ
[
https://issues.apache.org/jira/browse/LANG-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14068058#comment-14068058
]
Henri Yandell commented on LANG-1030:
-
It's getCommonPrefix.
Wish I could say I remembered that :) I started to write something about how
same was too close to equals and 'common' or 'commonPrefix' would be a
better name. Then noticed it was there :)
We should add @seeAlso javadoc to difference() pointing to the inverse being
getCommonPrefix.
StringUtils.same opposite method to StringUtils.differ
--
Key: LANG-1030
URL: https://issues.apache.org/jira/browse/LANG-1030
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 3.3.2
Reporter: Michael Bazos
Priority: Trivial
Labels: StringUtils
Fix For: Review Patch, Discussion
This is pretty easy to do but I have seen this come up and was surprised to
find that StringUtils didn't have a utility method.
The difference() method is described as doing the following:
Compares two Strings, and returns the portion where they differ.
What I am proposing is essentially the opposite of the difference method
called same(). This method would compare two String and return a new String
when they are the same.
This is essentially the implementation:
{code:java}
public static String same(String str1, String str2) {
if (str1 != null StringUtils.equalsIgnoreCase(str1, str2)) {
return new String(str1);
}
return null;
}
{code}
{code:java}
StringUtils.same(null, null) = null
StringUtils.same(, ) = ;
StringUtils.same(123, ) = null
StringUtils.same(123, 123) = 123;
{code}
If there is already a way to do this using the apache lang library please
point me in the right direction. Otherwise I would be more than happy to do
the testing, coding and documentation for this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-997) NumberUtil#isNumber() returns false for 012345678 but not for 12345678
[
https://issues.apache.org/jira/browse/LANG-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981869#comment-13981869
]
Henri Yandell commented on LANG-997:
Summarizing - the issue isn't that 0123 is bad, but that 012345678901234567 is
too big for Java.
In the same way, 0xfff should return false. It
currently returns true.
Also 9e is too large, but returns true currently.
I'm +1 to considering this a regression and accepting an isNumber that can
handle numbers larger than Java is prepared to handle. ie) Fixing this bug.
NumberUtil#isNumber() returns false for 012345678 but not for 12345678
--
Key: LANG-997
URL: https://issues.apache.org/jira/browse/LANG-997
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.3.2
Environment: Java 6
Reporter: Juan Pablo Santos Rodríguez
Fix For: Review Patch, 3.4
With commons-lang 3.2.1:
{code}
boolean ret = NumberUtils.isNumber( 012345678901234567 );
{code}
returns {{true}}, but for 3.3.2, returns {{false}}.
The change seems to be introduced in LANG-972 / LANG-992, as it seems to
consider now that, if the parameter string has a leading 0, and it's not hex,
then it must be forcibly octal.
As previous 3.x versions accept 0ddd as valid decimal numbers, the suggested
change on NumberUtils#isNumber, is to replace lines
[1367-1376|http://commons.apache.org/proper/commons-lang/xref/org/apache/commons/lang3/math/NumberUtils.html#L1367]
with:
{code}
} else if (Character.isDigit(chars[start + 1])) {
// leading 0, but not hex, must be octal or decimal
int i = start + 1;
for (; i chars.length; i++) {
if (chars[i] '0' || chars[i] '9') { // was: if
(chars[i] '0' || chars[i] '7') {
return false;
}
}
return true;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-341) Add number to byte array methods
[
https://issues.apache.org/jira/browse/LANG-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-341:
---
Fix Version/s: (was: 3.x)
Discussion
Add number to byte array methods
Key: LANG-341
URL: https://issues.apache.org/jira/browse/LANG-341
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Lilianne E. Blaze
Assignee: Duncan Jones
Fix For: Discussion
Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
LANG-341.patch
Hello,
I need a set of methods to convert Long to or from a byte[] array, as if
writing / reading from Data(Input/Output)Stream(
ByteArray(Input/Output)Stream ).
First, doing it with Streams seems a bit wasteful, second, it seems a
pretty general use. Would it be possible to add something like that to,
for example,
org.apache.commons.lang.math.NumberUtils?
Example code:
{code:java}
static public long toLong(byte[] b)
{
return toLong(b, 0);
}
static public long toLong(byte[] b, int offset)
{
return (((long)b[offset] 56) +
((long)(b[offset + 1] 255) 48) +
((long)(b[offset + 2] 255) 40) +
((long)(b[offset + 3] 255) 32) +
((long)(b[offset + 4] 255) 24) +
((b[offset + 5] 255) 16) +
((b[offset + 6] 255) 8) +
((b[offset + 7] 255) 0));
}
static public byte[] longToByteArray(long l)
{
byte b[] = new byte[8];
longToByteArray(l, b, 0);
return b;
}
static public void longToByteArray(long l, byte b[], int offset)
{
b[offset] = (byte)(l 56);
b[offset + 1] = (byte)(l 48);
b[offset + 2] = (byte)(l 40);
b[offset + 3] = (byte)(l 32);
b[offset + 4] = (byte)(l 24);
b[offset + 5] = (byte)(l 16);
b[offset + 6] = (byte)(l 8);
b[offset + 7] = (byte)(l 0);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-923) JDK 1.8 Changes
[ https://issues.apache.org/jira/browse/LANG-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-923: --- Component/s: General JDK 1.8 Changes --- Key: LANG-923 URL: https://issues.apache.org/jira/browse/LANG-923 Project: Commons Lang Issue Type: Task Components: General Reporter: Henri Yandell Fix For: 4.0 Omnibus issue to cover any JDK 1.8 related changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-967) Code should never catch and ignore all Throwables
[
https://issues.apache.org/jira/browse/LANG-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-967:
---
Component/s: lang.exception.*
Code should never catch and ignore all Throwables
-
Key: LANG-967
URL: https://issues.apache.org/jira/browse/LANG-967
Project: Commons Lang
Issue Type: New Feature
Components: lang.exception.*
Reporter: Sebb
Fix For: Patch Needed
Code should never catch and ignore all Throwables - ThreadDeath and
VirtualMachineError must be rethrown.
It would be useful to provide a method to enforce this behaviour.
For example,. as is done by the Tomcat method \[1] with source here \[2]
Sample usage:
{code}
try {
reader.close();
} catch (Throwable u) {
ExceptionUtils.handleThrowable(u);
}
{code}
\[1] org.apache.tomcat.util.ExceptionUtils#handleThrowable()
\[2]
https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/ExceptionUtils.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-986) DurationFormatUtils.formatDuration accepts formats with year/month but cannot use them
[ https://issues.apache.org/jira/browse/LANG-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-986: --- Component/s: lang.time.* DurationFormatUtils.formatDuration accepts formats with year/month but cannot use them -- Key: LANG-986 URL: https://issues.apache.org/jira/browse/LANG-986 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Reporter: Sebb Fix For: Discussion The method DurationFormatUtils.formatDuration does not validate that the format is applicable. The method does not calculate months and years, so these values will be 0 if the format contains y or M. Perhaps the method should throw IAE if one of the unused format chars is used? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-979) TypeUtils.parameterizeWithOwner - wrong format descriptor for invalid number of type parameters
[ https://issues.apache.org/jira/browse/LANG-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-979: --- Component/s: lang.reflect.* TypeUtils.parameterizeWithOwner - wrong format descriptor for invalid number of type parameters - Key: LANG-979 URL: https://issues.apache.org/jira/browse/LANG-979 Project: Commons Lang Issue Type: Bug Components: lang.reflect.* Reporter: Sebb Priority: Minor Fix For: Patch Needed The TypeUtils.parameterizeWithOwner method uses the following format string: invalid number of type parameters specified: expected %s, got %s with parameters that are actually ints. This means that the parameters are boxed into Integers and then converted to Strings by the formatter. Seems to me it would make more sense to either create the Strings directly from the ints, or box the ints and use %d for the place holders. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (IO-295) FileUtils.isSymlinks misses symlink folders on Windows
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened IO-295: -- Reopening per the comments. FileUtils.isSymlinks misses symlink folders on Windows -- Key: IO-295 URL: https://issues.apache.org/jira/browse/IO-295 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Environment: Windows 7 64 bit, Oracle Java 7 Reporter: Ron Gross Attachments: IO-295-1.patch, IO-295.patch I created a symlink folder via mklink. Then, while debugging, I noticed that FileUtils.isSymlink() returns false on this directory, while Java 7's Files.isSymbolicLink() returns true. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-986) DurationFormatUtils.formatDuration accepts formats with year/month but cannot use them
[ https://issues.apache.org/jira/browse/LANG-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-986: --- Fix Version/s: Discussion DurationFormatUtils.formatDuration accepts formats with year/month but cannot use them -- Key: LANG-986 URL: https://issues.apache.org/jira/browse/LANG-986 Project: Commons Lang Issue Type: Improvement Reporter: Sebb Fix For: Discussion The method DurationFormatUtils.formatDuration does not validate that the format is applicable. The method does not calculate months and years, so these values will be 0 if the format contains y or M. Perhaps the method should throw IAE if one of the unused format chars is used? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-965) FieldUtils methods leak accessible flags
[ https://issues.apache.org/jira/browse/LANG-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-965: --- Fix Version/s: Patch Needed FieldUtils methods leak accessible flags Key: LANG-965 URL: https://issues.apache.org/jira/browse/LANG-965 Project: Commons Lang Issue Type: Bug Components: lang.reflect.* Affects Versions: 3.1, 3.2.1 Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400) Maven home: C:\Java\apache-maven-3.1.1\bin\.. Java version: 1.7.0_51, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_51\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary Gregory Assignee: Gary Gregory Fix For: Patch Needed When various FieldUtils methods are called the accessible is set to true but never reset to false. This is side-effect should be cleaned up. This makes a mess of the object model which represents the class meta data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-967) Code should never catch and ignore all Throwables
[
https://issues.apache.org/jira/browse/LANG-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-967:
---
Fix Version/s: Patch Needed
Code should never catch and ignore all Throwables
-
Key: LANG-967
URL: https://issues.apache.org/jira/browse/LANG-967
Project: Commons Lang
Issue Type: New Feature
Reporter: Sebb
Fix For: Patch Needed
Code should never catch and ignore all Throwables - ThreadDeath and
VirtualMachineError must be rethrown.
It would be useful to provide a method to enforce this behaviour.
For example,. as is done by the Tomcat method \[1] with source here \[2]
Sample usage:
{code}
try {
reader.close();
} catch (Throwable u) {
ExceptionUtils.handleThrowable(u);
}
{code}
\[1] org.apache.tomcat.util.ExceptionUtils#handleThrowable()
\[2]
https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/ExceptionUtils.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-959) FieldUtils write methods do not write to final fields.
[ https://issues.apache.org/jira/browse/LANG-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-959: --- Fix Version/s: Review Patch FieldUtils write methods do not write to final fields. -- Key: LANG-959 URL: https://issues.apache.org/jira/browse/LANG-959 Project: Commons Lang Issue Type: Improvement Components: lang.reflect.* Affects Versions: 3.2.1 Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400) Maven home: C:\Java\apache-maven-3.1.1\bin\.. Java version: 1.7.0_51, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_51\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary Gregory Assignee: Gary Gregory Fix For: Review Patch Attachments: LANG-959.diff I have a use case where I need to use reflection to set a public static final Object. This does not work with our FieldUtils class because the forceAccess argument is only used to deal with field visibility by calling Field#setAccessible(boolean) Q1: Should forceAccess be expanded to remove the final modifier? Or: Q2: Should we add another boolean parameter forceWrite to remove the FINAL modifier? I like Q1. Q3: The Accessible flag is NOT reset if changed after a write! I think it should be. Thoughts? The attached patch implements this BUT does not fix failing tests that expect writes to fail on final fields. I left the tests failing to show clearly which ones fail so we can discuss if: - this fixes a bug, - is an improvement acceptable for the next release - or breaks too much for the next release Discuss here or on the ML. Thank you. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-979) TypeUtils.parameterizeWithOwner - wrong format descriptor for invalid number of type parameters
[ https://issues.apache.org/jira/browse/LANG-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-979: --- Fix Version/s: Patch Needed TypeUtils.parameterizeWithOwner - wrong format descriptor for invalid number of type parameters - Key: LANG-979 URL: https://issues.apache.org/jira/browse/LANG-979 Project: Commons Lang Issue Type: Bug Reporter: Sebb Priority: Minor Fix For: Patch Needed The TypeUtils.parameterizeWithOwner method uses the following format string: invalid number of type parameters specified: expected %s, got %s with parameters that are actually ints. This means that the parameters are boxed into Integers and then converted to Strings by the formatter. Seems to me it would make more sense to either create the Strings directly from the ints, or box the ints and use %d for the place holders. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-988) Where's the user guide?
[ https://issues.apache.org/jira/browse/LANG-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-988: --- Fix Version/s: Discussion Where's the user guide? --- Key: LANG-988 URL: https://issues.apache.org/jira/browse/LANG-988 Project: Commons Lang Issue Type: Bug Components: Website Affects Versions: 3.3 Reporter: Martin Schröder Priority: Minor Fix For: Discussion The homepage claims A getting started user guide is available together with various project reports. The link for the user guide (https://commons.apache.org/proper/commons-lang/userguide.html) then says Looking for the User Guide? It has been moved to the package JavaDoc - and the JavaDoc link points to the javadoc, where I can't find a user guide (do you mean the package summary of lang3 (https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/package-summary.html#package_description)? Oh, and IMHO the website should be a component in jira. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-985) ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
[
https://issues.apache.org/jira/browse/LANG-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-985:
---
Fix Version/s: Discussion
ToStringBuilder reliably handle OpenPojo @BusinessKey annotated instances
-
Key: LANG-985
URL: https://issues.apache.org/jira/browse/LANG-985
Project: Commons Lang
Issue Type: Wish
Components: lang.builder.*
Reporter: David Green
Priority: Minor
Labels: features
Fix For: Discussion
We use Google's OpenPojo library, annotating DTOs and persistence entities
with @BusinessKey in order to remove boilerplate hashcode() and equals().
I recently started noticing toString() was throwing exceptions when I didn't
populate @BusinessKey annotated field(s) as I was using the Null Object
Pattern. A workaround was to populate dummy values but there's a risk this
could be considered a real value further down the line, so looked for an
alternative solution and came up with the following extending
StandardToStringStyle:-
{code}
import org.apache.commons.lang3.builder.StandardToStringStyle;
import org.apache.commons.lang3.builder.ToStringStyle;
public class CustomToStringStyle extends StandardToStringStyle {
public static final ToStringStyle OPENPOJO_SAFE_STYLE =
createOpenPojoSafeStyle();
/**
* Works better with {@link com.openpojo.business.annotation.BusinessKey}
annotated OpenPojo classes.
*
* This instance does not call {@link ToStringStyle}.register(...)
* which can throw a {@link
com.openpojo.business.exception.BusinessException}
* if the key hasn't been populated, for example if you used the Null
Object Pattern.
*/
private static ToStringStyle createOpenPojoSafeStyle() {
final StandardToStringStyle style = new StandardToStringStyle();
style.setUseClassName(false);
style.setUseIdentityHashCode(false);
return style;
}
}
{code}
Used as follows:
{code}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
CustomToStringStyle.OPENPOJO_SAFE_STYLE);
}
{code}
I realise this doesn't handle recursion in fields because it skips over
ToStringStyle.register(..) but this suffices for our use case right now -
perhaps an alternative implementation overriding register() that uses a List
(with documented performance penalty) could be added.
Is there anything already in Commons that could do this? If not we would like
this to be considered for inclusion in commons lang (happy to help out with
development), potentially with implementation improvements by those who know
the code base better.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (LANG-936) StringUtils.getLevenshteinDistance with too big of a threshold returns wrong result
[
https://issues.apache.org/jira/browse/LANG-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878391#comment-13878391
]
Henri Yandell edited comment on LANG-936 at 1/22/14 8:20 AM:
-
Thanks Yaniv + Eli :)
svn ci -m Applying Eli Lindsey's patch to Yaniv Kunda's report in LANG-936
that StringUtils.getLevensteinDistance(String, String, int) gave the wrong
answer when the int threshold is near Integer.MAX_VALUE .
Sendingsrc/changes/changes.xml
Sendingsrc/main/java/org/apache/commons/lang3/StringUtils.java
Sendingsrc/test/java/org/apache/commons/lang3/StringUtilsTest.java
Transmitting file data ...
Committed revision 1560275.
was (Author: bayard):
Thanks Yanix + Eli :)
svn ci -m Applying Eli Lindsey's patch to Yaniv Kunda's report in LANG-936
that StringUtils.getLevensteinDistance(String, String, int) gave the wrong
answer when the int threshold is near Integer.MAX_VALUE .
Sendingsrc/changes/changes.xml
Sendingsrc/main/java/org/apache/commons/lang3/StringUtils.java
Sendingsrc/test/java/org/apache/commons/lang3/StringUtilsTest.java
Transmitting file data ...
Committed revision 1560275.
StringUtils.getLevenshteinDistance with too big of a threshold returns wrong
result
---
Key: LANG-936
URL: https://issues.apache.org/jira/browse/LANG-936
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Reporter: Yaniv Kunda
Priority: Minor
Fix For: 3.3
StringUtils.getLevenshteinDistance(CharSequence s, CharSequence t, int
threshold) specifies:
{quote}
{{Find the Levenshtein distance between two Strings if it's _+*less than or
equal to*+_ a given threshold.}}
{quote}
When passing a threshold *Integer.MAX_VALUE - max(s.length(), t.length())*
the method always returns -1.
The simplest use case is passing *Integer.MAX_VALUE* (a common practice if
one would want to find the min/max LD of a string to several other strings in
an iterative fashion.
The code should be fixed to consider the threshold in relation to the
source/target lengths, or alternatively the javadoc should be fixed to
pronounce the current limit.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (LANG-936) StringUtils.getLevenshteinDistance with too big of a threshold returns wrong result
[
https://issues.apache.org/jira/browse/LANG-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-936.
--
Resolution: Fixed
Fix Version/s: (was: Review Patch)
3.3
Thanks Yanix + Eli :)
svn ci -m Applying Eli Lindsey's patch to Yaniv Kunda's report in LANG-936
that StringUtils.getLevensteinDistance(String, String, int) gave the wrong
answer when the int threshold is near Integer.MAX_VALUE .
Sendingsrc/changes/changes.xml
Sendingsrc/main/java/org/apache/commons/lang3/StringUtils.java
Sendingsrc/test/java/org/apache/commons/lang3/StringUtilsTest.java
Transmitting file data ...
Committed revision 1560275.
StringUtils.getLevenshteinDistance with too big of a threshold returns wrong
result
---
Key: LANG-936
URL: https://issues.apache.org/jira/browse/LANG-936
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Reporter: Yaniv Kunda
Priority: Minor
Fix For: 3.3
StringUtils.getLevenshteinDistance(CharSequence s, CharSequence t, int
threshold) specifies:
{quote}
{{Find the Levenshtein distance between two Strings if it's _+*less than or
equal to*+_ a given threshold.}}
{quote}
When passing a threshold *Integer.MAX_VALUE - max(s.length(), t.length())*
the method always returns -1.
The simplest use case is passing *Integer.MAX_VALUE* (a common practice if
one would want to find the min/max LD of a string to several other strings in
an iterative fashion.
The code should be fixed to consider the threshold in relation to the
source/target lengths, or alternatively the javadoc should be fixed to
pronounce the current limit.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-942) Test failure in FastDateParserTest and FastDateFormat_ParserTest when building with JDK8
[
https://issues.apache.org/jira/browse/LANG-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862521#comment-13862521
]
Henri Yandell commented on LANG-942:
Seeing if I understand this right (paraphrasing Bruno):
The code is failing because the order in Java 8's timezone db changed. The
issue is not the test, but that our code is creating a lookup table with four
entries:
Timezone short name (this is unique).
Timezone long name (this isn't unique).
Timezone short w/ daylight saving. (per above)
Timezone long w/ daylight saving. (per above)
The two longs aren't unique, making them bad keys. Stepping away from the Map,
the issue is with the API of the class.
When parsing text that includes a TimeZone's long name, you can't guarantee
there is one answer. Thus we either:
a) Don't offer this feature. Which is easy, remove the two lines from the code
and any tests.
b) Choose one of the options.
c) Return all of them [not really feasible, or useful].
Presumably this bug would also appear on older versions of Java, ie: it's not
something special to the Java 7 to Java 8 transition.
Looking at SimpleDateFormat, it's matchTimeZone method appears to check the
same four items. It behaves differently, returning the first found in the array
rather than the last (as ours does). It would appear that the first one found
is America/New York. Presumably that's the same in Java 7 and 8 (and for all
- I bet they add new ones on the end, not the beginning).
So I think the main issue is in using TimeZone.getAvailableIDs and then
TimeZone.getTimeZone(id). Instead we should be using
java.text.DateFormatSymbols, and calling the getZoneStrings() method (thus (b)
above). We should also not put something in the map if it's already there to
match the first in rather than last in style. This does make this Oracle JDK
specific behaviour, but I suspect this code is the same in the various JDKs as
its typical use of the DateFormatSymbols. Its only our caching and use of a
different API that leads to weirdness.
The odd thing is that none of this suggests that we should see an error. It's a
rare use to get a Date from a formatter, and then ask the formatter exactly
which timezone it used to give you that date. Who cares if it's IET or Michigan
eh? Except we're talking about weird TimeZones and I'm betting that we're
adding a timezone to the map (with IET) that doesn't actually apply to Eastern
Daylight Time during the date we're discussing. Thus the value ends up an hour
off. There's a theoretical bug in the JDK here, except I bet they always put
the normal timezones above the weird ones, meaning the normal ones get chosen.
Hopefully this all sounds sane and not the ramblings of someone who should be
asleep :)
Test failure in FastDateParserTest and FastDateFormat_ParserTest when
building with JDK8
Key: LANG-942
URL: https://issues.apache.org/jira/browse/LANG-942
Project: Commons Lang
Issue Type: Sub-task
Components: lang.time.*
Affects Versions: 3.2
Environment: JDK8
Reporter: Benedikt Ritter
Fix For: 3.2.1, Patch Needed
The following failure is thrown when using JDK 8:
{code}
---
Test set: org.apache.commons.lang3.time.FastDateFormat_ParserTest
---
Tests run: 29, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.315 sec
FAILURE! - in org.apache.commons.lang3.time.FastDateFormat_ParserTest
testParseZone(org.apache.commons.lang3.time.FastDateFormat_ParserTest) Time
elapsed: 0.005 sec FAILURE!
java.lang.AssertionError: expected:Thu Jul 10 22:33:20 CEST 2003 but
was:Thu Jul 10 23:33:20 CEST 2003
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.commons.lang3.time.FastDateParserTest.testParseZone(FastDateParserTest.java:119)
[...]
{code}
It is caused by the following assertion in FastDateParserTest (from which
FastDateFormat_ParserTest inherits):
{code:java}
assertEquals(cal.getTime(), fdf.parse(2003-07-10T16:33:20.000 Eastern
Daylight Time));
{code}
{{FastDateParserTest}} fails with the same error.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (LANG-942) Test failure in FastDateParserTest and FastDateFormat_ParserTest when building with JDK8
[
https://issues.apache.org/jira/browse/LANG-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-942:
---
Fix Version/s: Patch Needed
Test failure in FastDateParserTest and FastDateFormat_ParserTest when
building with JDK8
Key: LANG-942
URL: https://issues.apache.org/jira/browse/LANG-942
Project: Commons Lang
Issue Type: Sub-task
Components: lang.time.*
Affects Versions: 3.2
Environment: JDK8
Reporter: Benedikt Ritter
Fix For: 3.2.1, Patch Needed
The following failure is thrown when using JDK 8:
{code}
---
Test set: org.apache.commons.lang3.time.FastDateFormat_ParserTest
---
Tests run: 29, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.315 sec
FAILURE! - in org.apache.commons.lang3.time.FastDateFormat_ParserTest
testParseZone(org.apache.commons.lang3.time.FastDateFormat_ParserTest) Time
elapsed: 0.005 sec FAILURE!
java.lang.AssertionError: expected:Thu Jul 10 22:33:20 CEST 2003 but
was:Thu Jul 10 23:33:20 CEST 2003
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.commons.lang3.time.FastDateParserTest.testParseZone(FastDateParserTest.java:119)
[...]
{code}
It is caused by the following assertion in FastDateParserTest (from which
FastDateFormat_ParserTest inherits):
{code:java}
assertEquals(cal.getTime(), fdf.parse(2003-07-10T16:33:20.000 Eastern
Daylight Time));
{code}
{{FastDateParserTest}} fails with the same error.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-939) Move Documentation from user guide to package-info files
[ https://issues.apache.org/jira/browse/LANG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862410#comment-13862410 ] Henri Yandell commented on LANG-939: Down side of this btw is that it ties our documentation to the release. Making a change means a release roll out and only new users get the improvements. Move Documentation from user guide to package-info files Key: LANG-939 URL: https://issues.apache.org/jira/browse/LANG-939 Project: Commons Lang Issue Type: Task Components: General Affects Versions: 3.2 Reporter: Benedikt Ritter Fix For: 3.3, Patch Needed As discussed on the ML [1], the user guide on the website currently contains documentation that would better suite in the corresponding package-info files. The Documentation should be split up and moved to those files. [1] http://markmail.org/message/jgyacp3pv3t43s4h -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (LANG-939) Move Documentation from user guide to package-info files
[ https://issues.apache.org/jira/browse/LANG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862410#comment-13862410 ] Henri Yandell edited comment on LANG-939 at 1/4/14 8:38 PM: Down side of this btw is that it ties our user guide to the release. Making a change means a release roll out and only new users get the improvements. Probably not a big issue though. was (Author: bayard): Down side of this btw is that it ties our documentation to the release. Making a change means a release roll out and only new users get the improvements. Move Documentation from user guide to package-info files Key: LANG-939 URL: https://issues.apache.org/jira/browse/LANG-939 Project: Commons Lang Issue Type: Task Components: General Affects Versions: 3.2 Reporter: Benedikt Ritter Fix For: 3.3, Patch Needed As discussed on the ML [1], the user guide on the website currently contains documentation that would better suite in the corresponding package-info files. The Documentation should be split up and moved to those files. [1] http://markmail.org/message/jgyacp3pv3t43s4h -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-939) Move Documentation from user guide to package-info files
[ https://issues.apache.org/jira/browse/LANG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861254#comment-13861254 ] Henri Yandell commented on LANG-939: This should be in 3.3 rather than 3.2.1 (assuming the plan is to get a 3.2.1 out as soon as possible). This item doesn't seem as pressing as the others. Move Documentation from user guide to package-info files Key: LANG-939 URL: https://issues.apache.org/jira/browse/LANG-939 Project: Commons Lang Issue Type: Task Components: General Affects Versions: 3.2 Reporter: Benedikt Ritter Fix For: 3.2.1, Patch Needed As discussed on the ML [1], the user guide on the website currently contains documentation that would better suite in the corresponding package-info files. The Documentation should be split up and moved to those files. [1] http://markmail.org/message/jgyacp3pv3t43s4h -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (LANG-933) Request to support custom DateFormatSymbols in FastDateFormat
[ https://issues.apache.org/jira/browse/LANG-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-933: --- Fix Version/s: Patch Needed Request to support custom DateFormatSymbols in FastDateFormat - Key: LANG-933 URL: https://issues.apache.org/jira/browse/LANG-933 Project: Commons Lang Issue Type: Bug Components: General Affects Versions: 3.1 Reporter: Egidijus Vaisnora Priority: Minor Fix For: Patch Needed FastDateFormat do not have possibility to accept custom DateFormatSymbols -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (OGNL-240) build unit test failure MethodTestOgnlTestCase.runTest:217-OgnlTestCase.assertEquals:196 expected:f[oo] but was:f[irst]
[ https://issues.apache.org/jira/browse/OGNL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened OGNL-240: Reopened per Jason's note on the mailing list that he's attached a patch, but nothing has been committed to svn. [Noting that Resolved = Committed to SVN] build unit test failure MethodTestOgnlTestCase.runTest:217-OgnlTestCase.assertEquals:196 expected:f[oo] but was:f[irst] - Key: OGNL-240 URL: https://issues.apache.org/jira/browse/OGNL-240 Project: Commons OGNL Issue Type: Bug Components: Core Runtime Affects Versions: 4.0 Environment: windows 64bit Reporter: Jason Pyeron Fix For: 4.0 Attachments: OGNL-240.patch, TEST-org.apache.commons.ognl.test.MethodTest.xml Running org.apache.commons.ognl.test.MethodTest Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0 sec FAILURE! runTest[3](org.apache.commons.ognl.test.MethodTest) Time elapsed: 0 sec FAILURE! org.junit.ComparisonFailure: expected:f[oo] but was:f[irst] at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.commons.ognl.test.OgnlTestCase.assertEquals(OgnlTestCase.java:196) at org.apache.commons.ognl.test.OgnlTestCase.runTest(OgnlTestCase.java:217) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854802#comment-13854802 ] Henri Yandell commented on LANG-769: Not enough support for UnhandledException. Issue already closed. Please restore NotImplementedException and UnhandledException - Key: LANG-769 URL: https://issues.apache.org/jira/browse/LANG-769 Project: Commons Lang Issue Type: Improvement Components: lang.exception.* Reporter: david cogen Priority: Minor Fix For: 3.2 Why were these removed? I found these very useful and used them often. As the version 2.6 api javadoc states, This exception supplements the standard exception classes by providing a more semantically rich description of the problem. Just want you to realize that these have found direct use outside the library; not just internal use within commons-lang. I will define these missing classes myself, or maybe include both commons-lang and commons-lang3 (but I really don't to do that). It would be very nice to have these back. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (LANG-763) Reintroduce DateUtils.UTC_TIME_ZONE constant
[
https://issues.apache.org/jira/browse/LANG-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819850#comment-13819850
]
Henri Yandell commented on LANG-763:
Noting that the patch applies cleanly and all tests pass.
Reintroduce DateUtils.UTC_TIME_ZONE constant
Key: LANG-763
URL: https://issues.apache.org/jira/browse/LANG-763
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.0.1
Reporter: Attila Király
Priority: Minor
Fix For: Review Patch
In LANG-691 DateUtils.UTC_TIME_ZONE was removed because TimeZone-s are
mutable. However it was a handy constant. So it would be nice if it could be
reintroduced in an immutable way. For example:
- by creating a new static method DateUtils.utcTimeZone() {return
TimeZone.getTimeZone(GMT);}
- or by creating an immutable timezone type (subclassing maybe SimpleTimeZone)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-863) Method returns number of inheritance hops between parent and subclass
[
https://issues.apache.org/jira/browse/LANG-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-863:
---
Fix Version/s: (was: Patch Needed)
Review Patch
Method returns number of inheritance hops between parent and subclass
-
Key: LANG-863
URL: https://issues.apache.org/jira/browse/LANG-863
Project: Commons Lang
Issue Type: New Feature
Components: lang.reflect.*
Reporter: Daneel S. Yaitskov
Fix For: Review Patch
Attachments: LANG-863.patch, LANG-863.patch
Original Estimate: 1h
Remaining Estimate: 1h
For example.
class A {
}
class B extends A {
}
class C extends B {
}
int d;
d = InheritanceUtils.distance(A.class, A.class);
Assert.assertEquals(0, d);
d = InheritanceUtils.distance(B.class, A.class);
Assert.assertEquals(1, d);
d = InheritanceUtils.distance(C.class, A.class);
Assert.assertEquals(2, d);
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-344) CollatorUtils - equivalent of StringUtils, but using Collators
[ https://issues.apache.org/jira/browse/LANG-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-344: --- Fix Version/s: (was: Patch Needed) Review Patch CollatorUtils - equivalent of StringUtils, but using Collators -- Key: LANG-344 URL: https://issues.apache.org/jira/browse/LANG-344 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: Review Patch Attachments: CollatorUtils.java, CollatorUtilsTest.java Stephen Kestle has pointed out that equalsIgnoreCase is an English/ASCII hack and that using the Collator class provides a more robust String comparison mechanism. - Most recently this came up when adding new ignore case methods to StringUtils for LANG-326 (also http://tinyurl.com/3d2jjk ) - Raised in regarding case insensitivity for EqualsBuilder and HashCodeBuilder in LANG-316 Creating this issue ticket so this doesn't get forgotten -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-344) CollatorUtils - equivalent of StringUtils, but using Collators
[ https://issues.apache.org/jira/browse/LANG-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812389#comment-13812389 ] Henri Yandell commented on LANG-344: Niall added a patch. CollatorUtils - equivalent of StringUtils, but using Collators -- Key: LANG-344 URL: https://issues.apache.org/jira/browse/LANG-344 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: Review Patch Attachments: CollatorUtils.java, CollatorUtilsTest.java Stephen Kestle has pointed out that equalsIgnoreCase is an English/ASCII hack and that using the Collator class provides a more robust String comparison mechanism. - Most recently this came up when adding new ignore case methods to StringUtils for LANG-326 (also http://tinyurl.com/3d2jjk ) - Raised in regarding case insensitivity for EqualsBuilder and HashCodeBuilder in LANG-316 Creating this issue ticket so this doesn't get forgotten -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-763) Reintroduce DateUtils.UTC_TIME_ZONE constant
[
https://issues.apache.org/jira/browse/LANG-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806474#comment-13806474
]
Henri Yandell commented on LANG-763:
First problem I hit is in building the code. The Timezone class has a new
method in Java 7 (observesDaylightTime()), so the code fails to build on
earlier versions.
Is it possible to extend SimpleTimeZone so this new method is hidden to our
source?
Reintroduce DateUtils.UTC_TIME_ZONE constant
Key: LANG-763
URL: https://issues.apache.org/jira/browse/LANG-763
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.0.1
Reporter: Attila Király
Priority: Minor
Fix For: Review Patch
In LANG-691 DateUtils.UTC_TIME_ZONE was removed because TimeZone-s are
mutable. However it was a handy constant. So it would be nice if it could be
reintroduced in an immutable way. For example:
- by creating a new static method DateUtils.utcTimeZone() {return
TimeZone.getTimeZone(GMT);}
- or by creating an immutable timezone type (subclassing maybe SimpleTimeZone)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806140#comment-13806140
]
Henri Yandell commented on LANG-916:
I just checked out the old r1535653 revision and it installs fine. If the
failing tests were time.* related, I strongly suspect it was related to the
system date/time of your machine.
The 2.x vs 3.x difference is weird; looking at it, I'm guessing that LANG-462
reintroduced the issue though I've not dug into the changelogs yet. It's a
little concerning that the LANG-538 and this fix aren't the same.
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch
Fix For: Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805134#comment-13805134
]
Henri Yandell commented on LANG-916:
Christian - are you able to test out Thomas' patch? I'm wary to rely on
successful builds on my side as they would have passed for 3.1 when that was
released.
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch
Fix For: Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (LANG-905) Compare between arrays
[ https://issues.apache.org/jira/browse/LANG-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-905. -- Resolution: Fixed Fix Version/s: (was: Review Patch) 3.2 svn ci -m Applying Thomas Neidhart's patch for LANG-905; fixing a bug in which EqualsBuilder considers two arrays of the same type to be equal, without considering the contents src Sendingsrc/changes/changes.xml Sendingsrc/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java Sending src/test/java/org/apache/commons/lang3/builder/EqualsBuilderTest.java Transmitting file data ... Committed revision 1535653. Compare between arrays -- Key: LANG-905 URL: https://issues.apache.org/jira/browse/LANG-905 Project: Commons Lang Issue Type: Bug Reporter: E Labels: patch Fix For: 3.2 Attachments: LANG-905.patch when comparing 2 arrays, EqualsBuilder returns true even if they contain different elements. example: Object[] o1 = new Object[1]; o1[0]=Hello; Object[] o2 = new Object[1]; o2[0]=Bye; System.out.println(EqualsBuilder.reflectionEquals(o1, o2, true)); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-901) endsWithAny is case sensitive - documented as case insensitive
[ https://issues.apache.org/jira/browse/LANG-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-901: --- Description: endsWithAny was added in response to this task: LANG-614 Documentation says that the method returns true if the CharSequence starts with any of the the prefixes, case insensitive, or both null StringUtils.endsWithAny(MIME/TYPE, TYPE) true StringUtils.endsWithAny(MIME/TYPE, type) false was: endsWithAny was added in response to this task: https://issues.apache.org/jira/browse/LANG-614 Documentation says that the method returns true if the CharSequence starts with any of the the prefixes, case insensitive, or both null StringUtils.endsWithAny(MIME/TYPE, TYPE) true StringUtils.endsWithAny(MIME/TYPE, type) false endsWithAny is case sensitive - documented as case insensitive -- Key: LANG-901 URL: https://issues.apache.org/jira/browse/LANG-901 Project: Commons Lang Issue Type: Bug Components: General Affects Versions: 3.1 Reporter: Matthew Bartenschlag Assignee: Benedikt Ritter Priority: Minor Fix For: Review Patch Attachments: LANG-901-StringUtils-StartsWithAnyEndsWithAny.patch endsWithAny was added in response to this task: LANG-614 Documentation says that the method returns true if the CharSequence starts with any of the the prefixes, case insensitive, or both null StringUtils.endsWithAny(MIME/TYPE, TYPE) true StringUtils.endsWithAny(MIME/TYPE, type) false -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805594#comment-13805594
]
Henri Yandell commented on LANG-916:
Could you list the tests that fail when you build/test straight out of svn? I
assume, from the committers involved, that we have people testing successfully
in US/Pacific, US/Eastern and CET timezones,
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch
Fix For: Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (LANG-928) Issue with OctalUnescaper
Henri Yandell created LANG-928: -- Summary: Issue with OctalUnescaper Key: LANG-928 URL: https://issues.apache.org/jira/browse/LANG-928 Project: Commons Lang Issue Type: Bug Components: lang.text.translate.* Reporter: Henri Yandell See this GitHub pull request: https://github.com/apache/commons-lang/pull/5 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-928) Issue with OctalUnescaper
[ https://issues.apache.org/jira/browse/LANG-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-928. -- Resolution: Fixed Fix Version/s: 3.2 svn ci -m Applying github pull request https://github.com/apache/commons-lang/pull/5, linked as LANG-928, fixing a bug in OctalEscaper trying to parse octal numbers longer than 3 digits . Sendingsrc/changes/changes.xml Sending src/main/java/org/apache/commons/lang3/text/translate/OctalUnescaper.java Sending src/test/java/org/apache/commons/lang3/text/translate/OctalUnescaperTest.java Transmitting file data ... Committed revision 1535911. Issue with OctalUnescaper - Key: LANG-928 URL: https://issues.apache.org/jira/browse/LANG-928 Project: Commons Lang Issue Type: Bug Components: lang.text.translate.* Reporter: Henri Yandell Fix For: 3.2 See this GitHub pull request: https://github.com/apache/commons-lang/pull/5 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (LANG-929) OctalUnescaper code is complex, leading to bugs
Henri Yandell created LANG-929: -- Summary: OctalUnescaper code is complex, leading to bugs Key: LANG-929 URL: https://issues.apache.org/jira/browse/LANG-929 Project: Commons Lang Issue Type: Improvement Components: lang.text.translate.* Reporter: Henri Yandell Assignee: Henri Yandell Fix For: Patch Needed My gut is that the code in OctalUnescaper is unnecessarily complex. It feels simpler to look at the legitimate values for an Octal more explicitly. Thinking the current code through, it fails if you pass it \279. That should be octal \27 followed by a 9, but instead it will try to parse it as an Octal and throw a NumberFormatException. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (LANG-929) OctalUnescaper code is complex, leading to bugs
[ https://issues.apache.org/jira/browse/LANG-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell resolved LANG-929. Resolution: Fixed Fix Version/s: (was: Patch Needed) 3.2 svn ci -m Rewriting OctalUnescaper as a hand rolled parser (all of 4 characters), instead of trying to handle the conversion via repeated attempts to convert the numbers. This fixes bugs, see LANG-929, and also changes the behaviour for 'illegal' octals such as \999. Instead of throwing NumberFormatException, it will now ignore them. This seems the better behaviour. Sending src/main/java/org/apache/commons/lang3/text/translate/OctalUnescaper.java Sending src/test/java/org/apache/commons/lang3/text/translate/OctalUnescaperTest.java Transmitting file data .. Committed revision 1535914. OctalUnescaper code is complex, leading to bugs --- Key: LANG-929 URL: https://issues.apache.org/jira/browse/LANG-929 Project: Commons Lang Issue Type: Improvement Components: lang.text.translate.* Reporter: Henri Yandell Assignee: Henri Yandell Fix For: 3.2 My gut is that the code in OctalUnescaper is unnecessarily complex. It feels simpler to look at the legitimate values for an Octal more explicitly. Thinking the current code through, it fails if you pass it \279. That should be octal \27 followed by a 9, but instead it will try to parse it as an Octal and throw a NumberFormatException. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-925) Deprecate o.a.c.lang.time.* package
[ https://issues.apache.org/jira/browse/LANG-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-925: --- Fix Version/s: (was: 3.2) Deprecate o.a.c.lang.time.* package --- Key: LANG-925 URL: https://issues.apache.org/jira/browse/LANG-925 Project: Commons Lang Issue Type: Task Components: lang.time.* Affects Versions: 3.1 Reporter: Benedikt Ritter Fix For: Discussion We have discussed [1] to deprecate the time package, because it will become obsolete in Java 8. [1] http://markmail.org/message/uw3lggwkt5ul5b7k -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-925) Deprecate o.a.c.lang.time.* package
[ https://issues.apache.org/jira/browse/LANG-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804594#comment-13804594 ] Henri Yandell commented on LANG-925: Agreed. Ideally we should push out a 3.x release as soon as we commit to rewriting the code in 4.x. Deprecate o.a.c.lang.time.* package --- Key: LANG-925 URL: https://issues.apache.org/jira/browse/LANG-925 Project: Commons Lang Issue Type: Task Components: lang.time.* Affects Versions: 3.1 Reporter: Benedikt Ritter Fix For: Discussion We have discussed [1] to deprecate the time package, because it will become obsolete in Java 8. [1] http://markmail.org/message/uw3lggwkt5ul5b7k -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804596#comment-13804596
]
Henri Yandell commented on LANG-848:
+1.
Let's resolve this one with varargs, then open a separate issue for Iterable
APIs, mentioning this as a use case. I'll get working on both of those.
Improve StringUtils.is(Not)Blank with a CharSequence... version
---
Key: LANG-848
URL: https://issues.apache.org/jira/browse/LANG-848
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.1
Reporter: Alexander Muthmann
Fix For: 3.2, Discussion
Currently it's only possible to compare a single CharSequence per
is(Not)Blank/is(Not)Empty call.
This should be changed to support multiple CharSequences in a single call.
{code}
if(StringUtils.isNotBlank(foo) StringUtils.isNotBlank(bar) ...)
{code}
could be changed to
{code}
if(StringUtils.isNotBlank(foo, bar, ...)
{code}
As there are two possible ways to combine the results (AND and OR), it'd be
necessary to create multiple methods.
{code}
isAnyBlank(CharSequence... cs)
isNoneBlank(CharSequence... cs)
isAnyEmpty(CharSequence... cs)
isNoneEmpty(CharSequence... cs)
{code}
I could implement those methods and contribute them via github if there is
any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804614#comment-13804614
]
Henri Yandell commented on LANG-848:
Patch applied:
svn ci -m Applying Alexander Muthmann's patch from LANG-848, adding
isBlank/isEmpty CharSequence... variants src
Sendingsrc/main/java/org/apache/commons/lang3/StringUtils.java
Sendingsrc/test/java/org/apache/commons/lang3/StringUtilsTest.java
Transmitting file data ..
Committed revision 1535515.
Improve StringUtils.is(Not)Blank with a CharSequence... version
---
Key: LANG-848
URL: https://issues.apache.org/jira/browse/LANG-848
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.1
Reporter: Alexander Muthmann
Fix For: 3.2
Currently it's only possible to compare a single CharSequence per
is(Not)Blank/is(Not)Empty call.
This should be changed to support multiple CharSequences in a single call.
{code}
if(StringUtils.isNotBlank(foo) StringUtils.isNotBlank(bar) ...)
{code}
could be changed to
{code}
if(StringUtils.isNotBlank(foo, bar, ...)
{code}
As there are two possible ways to combine the results (AND and OR), it'd be
necessary to create multiple methods.
{code}
isAnyBlank(CharSequence... cs)
isNoneBlank(CharSequence... cs)
isAnyEmpty(CharSequence... cs)
isNoneEmpty(CharSequence... cs)
{code}
I could implement those methods and contribute them via github if there is
any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (LANG-927) Create Iterable APIs
Henri Yandell created LANG-927:
--
Summary: Create Iterable APIs
Key: LANG-927
URL: https://issues.apache.org/jira/browse/LANG-927
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Reporter: Henri Yandell
Fix For: Discussion
LANG-848 suggests having Iterable APIs in addition to CharSequence... (or
potentially other vararg methods).
Currently we have 10 Iterable APIs:
ClassUtils.hierarchy(final Class? type) {
ClassUtils.hierarchy(final Class? type, Interfaces interfacesBehavior) {
EnumUtils.generateBitVector(final ClassE enumClass, final IterableE values)
{
EnumUtils.generateBitVectors(final ClassE enumClass, final IterableE
values) {
StringUtils.join(final Iterable? iterable, final char separator) {
StringUtils.join(final Iterable? iterable, final String separator) {
StrBuilder.java.StrBuilder appendAll(final Iterable? iterable) {
StrBuilder.appendWithSeparators(final Iterable? iterable, String separator) {
Validate.noNullElements(final T iterable, final String message, final Object...
values) {
Validate.noNullElements(final T iterable) {
There are many other methods that could have such, but continuing to add
Iterable wherever we see varargs is going to bloat the API.
Perhaps adding a method to ArrayUtils (or IteratorUtils) can suffice:
public static E[] iteratorToArray(IteratorE iterator);
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-848.
--
Resolution: Fixed
Fix Version/s: (was: Discussion)
Resolving the issue - thanks Alexander :)
Improve StringUtils.is(Not)Blank with a CharSequence... version
---
Key: LANG-848
URL: https://issues.apache.org/jira/browse/LANG-848
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.1
Reporter: Alexander Muthmann
Fix For: 3.2
Currently it's only possible to compare a single CharSequence per
is(Not)Blank/is(Not)Empty call.
This should be changed to support multiple CharSequences in a single call.
{code}
if(StringUtils.isNotBlank(foo) StringUtils.isNotBlank(bar) ...)
{code}
could be changed to
{code}
if(StringUtils.isNotBlank(foo, bar, ...)
{code}
As there are two possible ways to combine the results (AND and OR), it'd be
necessary to create multiple methods.
{code}
isAnyBlank(CharSequence... cs)
isNoneBlank(CharSequence... cs)
isAnyEmpty(CharSequence... cs)
isNoneEmpty(CharSequence... cs)
{code}
I could implement those methods and contribute them via github if there is
any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-806) RandomStringUtils can enter infinite loop if chosen char does not meet letter/digit requirements
[ https://issues.apache.org/jira/browse/LANG-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804626#comment-13804626 ] Henri Yandell commented on LANG-806: I haven't thought on the solution yet, but on the Exception, I'm tempted by a more generic exception. TooManyTriesException(String, Throwable). RandomStringUtils can enter infinite loop if chosen char does not meet letter/digit requirements Key: LANG-806 URL: https://issues.apache.org/jira/browse/LANG-806 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 2.6, 3.1 Reporter: Sebb Fix For: Review Patch Attachments: LANG-806.patch, RandomStringException.java An infinite loop can result if the selection process never returns a char that passes the validation test. This can occur if the subset specified by the start and end characters does not contain any valid characters. For example: RandomStringUtils.random(3, 5, 10, true, true); // 1 RandomStringUtils.random(3, 56192, 56319, false, false); // 2 There's also the case where only surrogates are allowed, but the buffer is not an even number of characters, for example: RandomStringUtils.random(3, 56320, 57343, false, false); // 3 The second example is easy to detect, but in general it does not seem easy to determine in advance if the subset contains any valid characters - except by evaluating all the possible char values. This would be expensive if the subset range is large. One possibility is to count the total number of loops (or retries), and throw an error if it exceeds a given value. Or count the number of consecutive retries. In both cases the threshold value must be set high enough to allow for the cases where the allowable char range contains only a small proportion of valid characters. In the case of digits only, the default allowable range is currently set to digits + letters, so the proportion of valid chars is 10/90 i.e. approx 11%. A minimum proportion of 1% or 0.1% would be necessary to reduce the number of false positives. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-917) Exception when combining custom and choice format in ExtendedMessageFormat
[
https://issues.apache.org/jira/browse/LANG-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-917.
--
Resolution: Fixed
svn ci -m Applying Thomas' patch from LANG-917 - fixing Arne Burmeister's
reported exception when combining custom and choice formats
Sendingsrc/changes/changes.xml
Sending
src/main/java/org/apache/commons/lang3/text/ExtendedMessageFormat.java
Sending
src/test/java/org/apache/commons/lang3/text/ExtendedMessageFormatTest.java
Transmitting file data ...
Committed revision 1535547.
Exception when combining custom and choice format in ExtendedMessageFormat
--
Key: LANG-917
URL: https://issues.apache.org/jira/browse/LANG-917
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 2.5, 2.6
Reporter: Arne Burmeister
Labels: patch
Fix For: 3.2
Attachments: ExtendedMessageFormatTest.java, LANG-917.patch
When using a custom format registered and a choice format with an inner
format is used in the same message format, an IndexOutOfBoundsException
occurs in the custructor of ExtendedMessageFormat:
{code:java}new ExtendedMessageFormat(Hi {0,test,any}, got
{1,choice,0#none|1#one|1{1,number}}, Collections.singletonMap(test, new
TestFormatFactory()));{code}
{noformat}
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at
org.apache.commons.lang.text.ExtendedMessageFormat.insertFormats(ExtendedMessageFormat.java:364)
at
org.apache.commons.lang.text.ExtendedMessageFormat.applyPattern(ExtendedMessageFormat.java:192)
at
org.apache.commons.lang.text.ExtendedMessageFormat.init(ExtendedMessageFormat.java:127)
{noformat}
The problem occurs at the start of {{\{1,number\}}}.
As a workaround i registered the {{TestFormatFactory}} also for choice and
then returning {{new ChoiceFormat(arguments)}}, but that is not the idea.
I also checked the change logs, but there seems no change on this problem. I
have not tester, but I think the bug still is present in the current release.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-917) Exception when combining custom and choice format in ExtendedMessageFormat
[
https://issues.apache.org/jira/browse/LANG-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-917:
---
Fix Version/s: (was: Review Patch)
3.2
Exception when combining custom and choice format in ExtendedMessageFormat
--
Key: LANG-917
URL: https://issues.apache.org/jira/browse/LANG-917
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 2.5, 2.6
Reporter: Arne Burmeister
Labels: patch
Fix For: 3.2
Attachments: ExtendedMessageFormatTest.java, LANG-917.patch
When using a custom format registered and a choice format with an inner
format is used in the same message format, an IndexOutOfBoundsException
occurs in the custructor of ExtendedMessageFormat:
{code:java}new ExtendedMessageFormat(Hi {0,test,any}, got
{1,choice,0#none|1#one|1{1,number}}, Collections.singletonMap(test, new
TestFormatFactory()));{code}
{noformat}
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at
org.apache.commons.lang.text.ExtendedMessageFormat.insertFormats(ExtendedMessageFormat.java:364)
at
org.apache.commons.lang.text.ExtendedMessageFormat.applyPattern(ExtendedMessageFormat.java:192)
at
org.apache.commons.lang.text.ExtendedMessageFormat.init(ExtendedMessageFormat.java:127)
{noformat}
The problem occurs at the start of {{\{1,number\}}}.
As a workaround i registered the {{TestFormatFactory}} also for choice and
then returning {{new ChoiceFormat(arguments)}}, but that is not the idea.
I also checked the change logs, but there seems no change on this problem. I
have not tester, but I think the bug still is present in the current release.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (LANG-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-774. -- Resolution: Fixed Fix Version/s: (was: Review Patch) 3.2 Applied :) svn ci -m Applying Sebb's patch from LANG-774 - adding isStarted, isSuspended and isStopped to StopWatch Sendingsrc/changes/changes.xml Sendingsrc/main/java/org/apache/commons/lang3/time/StopWatch.java Sendingsrc/test/java/org/apache/commons/lang3/time/StopWatchTest.java Transmitting file data ... Committed revision 153. Add isStarted isStopped and isSuspended to StopWatch Key: LANG-774 URL: https://issues.apache.org/jira/browse/LANG-774 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Affects Versions: 3.1 Reporter: Michael Akerman Priority: Minor Labels: features Fix For: 3.2 Attachments: LANG774_1.diff, LANG774_2.patch, LANG774.diff, StopWatch.java Original Estimate: 2h Remaining Estimate: 2h It would be nice to have: isStarted isStopped isSuspended On StopWatch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801978#comment-13801978
]
Henri Yandell commented on LANG-909:
Agreed - the proposal for Lang 4.0 is to be Java 8 compatible. So my note is
meant to read as 'would we be removing this in Lang 4.0?'
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Fix For: Review Patch
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-456: --- Fix Version/s: (was: Patch Needed) Review Patch HashCodeBuilder throws StackOverflowError in bidirectional navigable association Key: LANG-456 URL: https://issues.apache.org/jira/browse/LANG-456 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 2.4 Environment: Widows XP. Sun JDK 1.5 or 1.6. Reporter: Bob Fields Fix For: Review Patch Attachments: HashCodeBuilderStackOverflow.zip, LANG-456-patch.txt, StackOverflowError.zip This is not the reflection methods, it is the regular HashCodeBuilder append methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also throw the StackOverflowException, but those methods work when one of the HashCodeBuilder bidirectional association attributes .hashCode() is commented out. The problem is that all of the builders call registerObject() which creates a hashCode, but only the reflectionAppend method checks if an object is registered. Bi-directional associations are a very common pattern in Jaxb and Hibernate. In this case, I generate code from a model in order to avoid the reflection penalty - I already know what the attributes are at compile time, so I use .append instead of .reflectionAppend. See attached example + unit test. One side of the bidirectional association must be commented out in the hashCode method. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801990#comment-13801990 ] Henri Yandell commented on LANG-456: Thanks Woonsan :) Moving to Review Patch. HashCodeBuilder throws StackOverflowError in bidirectional navigable association Key: LANG-456 URL: https://issues.apache.org/jira/browse/LANG-456 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 2.4 Environment: Widows XP. Sun JDK 1.5 or 1.6. Reporter: Bob Fields Fix For: Review Patch Attachments: HashCodeBuilderStackOverflow.zip, LANG-456-patch.txt, StackOverflowError.zip This is not the reflection methods, it is the regular HashCodeBuilder append methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also throw the StackOverflowException, but those methods work when one of the HashCodeBuilder bidirectional association attributes .hashCode() is commented out. The problem is that all of the builders call registerObject() which creates a hashCode, but only the reflectionAppend method checks if an object is registered. Bi-directional associations are a very common pattern in Jaxb and Hibernate. In this case, I generate code from a model in order to avoid the reflection penalty - I already know what the attributes are at compile time, so I use .append instead of .reflectionAppend. See attached example + unit test. One side of the bidirectional association must be commented out in the hashCode method. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802010#comment-13802010 ] Henri Yandell commented on LANG-910: Gotya. Sounds reasonable. I agree with the [0] group being supported btw. I'm going to drop the 3.2 off this for the moment as the patch needs more work. I also wonder if it should go in a PatternUtils. Patch to extend StringUtils --- Key: LANG-910 URL: https://issues.apache.org/jira/browse/LANG-910 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Environment: Developed on Ubuntu 13.04 with openjdk 7u25 Reporter: Timur Yarosh Labels: patch Fix For: Discussion Attachments: LANG-910.patch, substring-matches-and-white-space-normalize.patch This patch extends StringUtils capabilities: added methods to find substring(s) by Pattern. Also method org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 char to normal whitespace. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-910: --- Fix Version/s: (was: 3.2) Patch to extend StringUtils --- Key: LANG-910 URL: https://issues.apache.org/jira/browse/LANG-910 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Environment: Developed on Ubuntu 13.04 with openjdk 7u25 Reporter: Timur Yarosh Labels: patch Fix For: Discussion Attachments: LANG-910.patch, substring-matches-and-white-space-normalize.patch This patch extends StringUtils capabilities: added methods to find substring(s) by Pattern. Also method org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 char to normal whitespace. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-782) Specialized StringBuilder to allow simple creating of Strings from base Strings with variable arguments and proper punctuation
[ https://issues.apache.org/jira/browse/LANG-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-782: --- Fix Version/s: Review Patch Specialized StringBuilder to allow simple creating of Strings from base Strings with variable arguments and proper punctuation -- Key: LANG-782 URL: https://issues.apache.org/jira/browse/LANG-782 Project: Commons Lang Issue Type: New Feature Components: lang.builder.* Reporter: Darryl Smith Priority: Minor Fix For: Review Patch Attachments: EnhancedBuilder.java Original Estimate: 24h Remaining Estimate: 24h Programmers frequently encounter a situation where there is a need to display messages to users. This functionality is useful where there are logical rules around how to punctuate lists of items or other situations. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-572) [XSS] StringEscapeUtils.escapeHtml() must escape ' chars to #39;
[ https://issues.apache.org/jira/browse/LANG-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-572: --- Fix Version/s: Discussion [XSS] StringEscapeUtils.escapeHtml() must escape ' chars to #39; -- Key: LANG-572 URL: https://issues.apache.org/jira/browse/LANG-572 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 2.4 Environment: Operating System: All Platform: All Reporter: Keisuke Kato Priority: Minor Fix For: Discussion If developers putting untrusted data into attribute values using the single quote character ' and StringEscapeUtils.escapeHtml() like: input type='text' name='input' 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='* input type='text' name='input' 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.1#6144)
[jira] [Updated] (LANG-757) StringEscapeUtils.unescapeHtml: handle HTML escapes without semicolon
[ https://issues.apache.org/jira/browse/LANG-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-757: --- Fix Version/s: Discussion StringEscapeUtils.unescapeHtml: handle HTML escapes without semicolon - Key: LANG-757 URL: https://issues.apache.org/jira/browse/LANG-757 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Steve Hale Priority: Minor Fix For: Discussion 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 # 60; or lt; (remove spaces) into normal chars like so patterns like HTML tags can be detected. Many browsers will allow variations without semicolons, particularly the long UTF-8 encoding like #060. Please see: http://ha.ckers.org/xss.html Since this may not be standard HTML, maybe adding a boolean bLenient parameter to the method could allow better backward compatibility. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-909:
---
Fix Version/s: Review Patch
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Fix For: Review Patch
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-900) New RandomUtils class
[
https://issues.apache.org/jira/browse/LANG-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-900:
---
Fix Version/s: Review Patch
New RandomUtils class
-
Key: LANG-900
URL: https://issues.apache.org/jira/browse/LANG-900
Project: Commons Lang
Issue Type: New Feature
Reporter: Duncan Jones
Priority: Minor
Fix For: Review Patch
Attachments: RandomUtils.java, RandomUtilsTest.java
Attached is a new {{RandomUtils}} class and associated test, which offers
some methods not available in the standard {{Random}} class:
- a {{nextBytes(int count)}} method that returns a byte array
- versions of {{nextInt}}, {{nextLong}}, {{nextFloat}} and {{nextDouble}}
that return a value within a range.
Comments very welcome!
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-901) endsWithAny is case sensitive - documented as case insensitive
[ https://issues.apache.org/jira/browse/LANG-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-901: --- Fix Version/s: Review Patch endsWithAny is case sensitive - documented as case insensitive -- Key: LANG-901 URL: https://issues.apache.org/jira/browse/LANG-901 Project: Commons Lang Issue Type: Bug Components: General Affects Versions: 3.1 Reporter: Matthew Bartenschlag Assignee: Benedikt Ritter Priority: Minor Fix For: Review Patch Attachments: LANG-901-StringUtils-StartsWithAnyEndsWithAny.patch endsWithAny was added in response to this task: https://issues.apache.org/jira/browse/LANG-614 Documentation says that the method returns true if the CharSequence starts with any of the the prefixes, case insensitive, or both null StringUtils.endsWithAny(MIME/TYPE, TYPE) true StringUtils.endsWithAny(MIME/TYPE, type) false -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-895) Improving StringUtils#substringAfterLast
[ https://issues.apache.org/jira/browse/LANG-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-895: --- Fix Version/s: Patch Needed Improving StringUtils#substringAfterLast Key: LANG-895 URL: https://issues.apache.org/jira/browse/LANG-895 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Environment: any Reporter: Ivan Hristov Priority: Minor Fix For: Patch Needed At the moment, we have the following method public static String substringAfterLast(String str, String separator) in the class StringUtils which returns an empty string in case no separator is present. I think, it would be handy to be able to control what is returned in case no separator is found. For this reason, I would propose to have a method with the following signature: public static String substringAfterLast(String str, String separator, String defaultValue). The same proposal holds for public static String substringAfter(String str, String separator). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800989#comment-13800989
]
Henri Yandell commented on LANG-909:
Marking as Review Patch; though a question to ask here is what we would do with
this code in Java 8. Does it remove the need for this.
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Fix For: Review Patch
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-742) [IgnoreCase] methods for ArrayUtils
[ https://issues.apache.org/jira/browse/LANG-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-742: --- Fix Version/s: Review Patch [IgnoreCase] methods for ArrayUtils --- Key: LANG-742 URL: https://issues.apache.org/jira/browse/LANG-742 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Michael Lyons Priority: Minor Fix For: Review Patch Attachments: StringArrayUtils.java, StringArrayUtilsTest.java This is a proposal for a feature addition. On several projects, I've needed to perform case insensitive manipulation on Arrays of Strings. My original need was just a solution for containsIgnoreCase(String[], String) and indexOfIgnoreCase(String[], String). In an effort to keep things simple, I created this class which implements 8 [IgnoreCase] methods that could be a benefit to Commons Lang users. StringArrayUtils extends ArrayUtils, it provides case insensitive manipulation on an Array of Strings. The new methods provided in the class are: containsIgnoreCase(String[] array, String stringToFind) indexOfIgnoreCase(String[] array, String stringToFind) indexOfIgnoreCase(String[] array, String stringToFind, int startIndex) isEqualsIgnoreCase(String[] array1, String[] array2) lastIndexOfIgnoreCase(String[] array, String stringToFind) lastIndexOfIgnoreCase(String[] array, String stringToFind, int startIndex) removeElementIgnoreCase(String[] array, String element) removeElementsIgnoreCase(String[] array, String... values) These eight methods cover the functional pattern provided in ArrayUtils. Any comparison in ArrayUtils based on obj1.equals(obj2) now has an equivalent str1.equalsIgnoreCase(str2) in StringArrayUtils. I've included a test case and have made efforts to match your coding convention and style. Thanks in advance for your time and consideration. I'd be happy to follow up with any changes or edits if you think this is something that might be included in a future version of Commons Lang. ...Mike Ps. I understand that handling a special case for the String's equalsIgnoreCase(...) may be a slippery slope - which has been intentionally avoided. I have also considered overloading the above eight methods with a Comparator parameter, but requiring a user to pass in a not-null, case-insensitive comparator didn't seem as straight forward as the above solution. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-895) Improving StringUtils#substringAfterLast
[ https://issues.apache.org/jira/browse/LANG-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-895: --- Fix Version/s: Review Patch Improving StringUtils#substringAfterLast Key: LANG-895 URL: https://issues.apache.org/jira/browse/LANG-895 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Environment: any Reporter: Ivan Hristov Priority: Minor Fix For: Review Patch At the moment, we have the following method public static String substringAfterLast(String str, String separator) in the class StringUtils which returns an empty string in case no separator is present. I think, it would be handy to be able to control what is returned in case no separator is found. For this reason, I would propose to have a method with the following signature: public static String substringAfterLast(String str, String separator, String defaultValue). The same proposal holds for public static String substringAfter(String str, String separator). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-787) StringUtils.RemoveIgnoreCase desired
[ https://issues.apache.org/jira/browse/LANG-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-787: --- Fix Version/s: Review Patch StringUtils.RemoveIgnoreCase desired Key: LANG-787 URL: https://issues.apache.org/jira/browse/LANG-787 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Reporter: david cogen Priority: Minor Fix For: Review Patch Attachments: IgnoreCaseForRemoveAndReplace.patch removeStartIgnoreCase() and removeEndIgnoreCase() exist, so why not removeIgnoreCase() Specifically: String removeIgnoreCase(String str, String remove) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-895) Improving StringUtils#substringAfterLast
[ https://issues.apache.org/jira/browse/LANG-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-895: --- Fix Version/s: (was: Patch Needed) Improving StringUtils#substringAfterLast Key: LANG-895 URL: https://issues.apache.org/jira/browse/LANG-895 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Environment: any Reporter: Ivan Hristov Priority: Minor Fix For: Review Patch At the moment, we have the following method public static String substringAfterLast(String str, String separator) in the class StringUtils which returns an empty string in case no separator is present. I think, it would be handy to be able to control what is returned in case no separator is found. For this reason, I would propose to have a method with the following signature: public static String substringAfterLast(String str, String separator, String defaultValue). The same proposal holds for public static String substringAfter(String str, String separator). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-823) StringUtils.split should handle empty strings the same as other content
[
https://issues.apache.org/jira/browse/LANG-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-823:
---
Fix Version/s: Review Patch
StringUtils.split should handle empty strings the same as other content
---
Key: LANG-823
URL: https://issues.apache.org/jira/browse/LANG-823
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 2.5
Reporter: Mark Farnsworth
Priority: Minor
Fix For: Review Patch
Attachments: LANG-823.patch, LANG-823.test.patch
When a user issues a split with a delimiter and the string does not contain
the delimiter the result is normally an array with one item that contains the
content of the string.
It seems strange that StringUtils does not behave consistently in the context
of an empty string.
For example,
{code}
package maf.test;
import junit.framework.TestCase;
import org.apache.commons.lang.StringUtils;
public class StringUtilsTest extends TestCase {
public void testStringUtils() {
// The following two lines work correctly
assertTrue(StringUtils.split(x,,)[0].equals(x));
assertTrue(StringUtils.split( ,,)[0].equals( ));
// The following should also work but
// in commons-lang-2.5.jar the test fails here
assertTrue(StringUtils.split(,,)[0].equals());
}
}
{code}
There seems to be no logic behind making split work differently in the case
of empty strings.
For the next release, I would suggest a behavior change for StringUtils this
will have side effects but would be more logically consistent.
Users who depend on the old behavior could stick with 2.5 release and/or
implement code in the caller to simulate the behavior.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-872) EqualsBuilder methods append(Object[],Object[]) and append(Object,Object) treats array class dirrerently
[
https://issues.apache.org/jira/browse/LANG-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-872:
---
Fix Version/s: Discussion
EqualsBuilder methods append(Object[],Object[]) and append(Object,Object)
treats array class dirrerently
Key: LANG-872
URL: https://issues.apache.org/jira/browse/LANG-872
Project: Commons Lang
Issue Type: Bug
Components: lang.builder.*
Affects Versions: 2.6, 3.1
Reporter: Algirdas Raščius
Priority: Minor
Fix For: Discussion
Attachments: commons-lang3-LANG-872.patch
Method {{EqualsBuilder.append(Object[],Object[])}} ignores classes of passed
arrays and returns true if contents of both arrays are equal.
Method {{EqualsBuilder.append(Object,Object)}} returns false immediately if
types of passed array arguments are different.
For example:
{code}
public void testEqualsArrays() {
Object[] aArray = new Object[] {Value};
Object[] bArray = new String[] {Value};
boolean compareAsArrays = new EqualsBuilder().append(aArray,
bArray).isEquals();
// compareAsArrays is true
Object aObj = aArray;
Object bObj = bArray;
boolean compareAsObjects = new EqualsBuilder().append(aObj,
bObj).isEquals();
// compareAsObjects is false
assertTrue(compareAsArrays == compareAsObjects); //Fails
}
{code}
Results of both methods should be consistent.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-819) EnumUtils.generateBitVector needs a ? extends
[
https://issues.apache.org/jira/browse/LANG-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-819:
---
Fix Version/s: Review Patch
EnumUtils.generateBitVector needs a ? extends
---
Key: LANG-819
URL: https://issues.apache.org/jira/browse/LANG-819
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Reporter: Shevek
Priority: Minor
Fix For: Review Patch
public static E extends EnumE long generateBitVector(ClassE
enumClass, IterableE values) {
Should be Iterable? extends E.
This is because although no subclasses of E can exist, the ? extends is a
common idiom for marking the collection as readonly, or not owned by the
current object.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-917) Exception when combining custom and choice format in ExtendedMessageFormat
[
https://issues.apache.org/jira/browse/LANG-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-917:
---
Fix Version/s: Review Patch
Exception when combining custom and choice format in ExtendedMessageFormat
--
Key: LANG-917
URL: https://issues.apache.org/jira/browse/LANG-917
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 2.5, 2.6
Reporter: Arne Burmeister
Labels: patch
Fix For: Review Patch
Attachments: ExtendedMessageFormatTest.java, LANG-917.patch
When using a custom format registered and a choice format with an inner
format is used in the same message format, an IndexOutOfBoundsException
occurs in the custructor of ExtendedMessageFormat:
{code:java}new ExtendedMessageFormat(Hi {0,test,any}, got
{1,choice,0#none|1#one|1{1,number}}, Collections.singletonMap(test, new
TestFormatFactory()));{code}
{noformat}
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at
org.apache.commons.lang.text.ExtendedMessageFormat.insertFormats(ExtendedMessageFormat.java:364)
at
org.apache.commons.lang.text.ExtendedMessageFormat.applyPattern(ExtendedMessageFormat.java:192)
at
org.apache.commons.lang.text.ExtendedMessageFormat.init(ExtendedMessageFormat.java:127)
{noformat}
The problem occurs at the start of {{\{1,number\}}}.
As a workaround i registered the {{TestFormatFactory}} also for choice and
then returning {{new ChoiceFormat(arguments)}}, but that is not the idea.
I also checked the change logs, but there seems no change on this problem. I
have not tester, but I think the bug still is present in the current release.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-878) Create a service implementation
[ https://issues.apache.org/jira/browse/LANG-878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-878: --- Fix Version/s: Patch Needed Create a service implementation --- Key: LANG-878 URL: https://issues.apache.org/jira/browse/LANG-878 Project: Commons Lang Issue Type: Wish Components: lang.concurrent.* Reporter: offbynull Priority: Minor Fix For: Patch Needed It would be nice if commons lang had a Service class for threading -- similar to the one provided by Guava, but without Guava's poorly designed API and excess baggage. This would essentially be a thread with an initialization method and a shutdown method (along with the actual run method). The thread creating the service would block until the initialization finishes successfully, and the service would call shutdown when it finishes (or if it gets interrupted). You would be able to query the state of the Service at any time. It would live in the concurrent package. -- This message was sent by Atlassian JIRA (v6.1#6144)
