[jira] [Updated] (COMPRESS-327) Support in-memory processing for ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic updated COMPRESS-327: -- Attachment: (was: seekable-input-stream.txt) > Support in-memory processing for ZipFile > > > Key: COMPRESS-327 > URL: https://issues.apache.org/jira/browse/COMPRESS-327 > Project: Commons Compress > Issue Type: New Feature >Reporter: Brett Kail >Priority: Minor > Attachments: > 0001-Add-a-SeekableInputStream-and-some-subclasses-that-Z.patch > > > ZipFile (and SevenZFile) currently require a File argument, but it would be > nice to support in-memory byte buffers rather than requiring temp files. > Perhaps create a new SeekableInputStream class (or SeekableDataInput > interface) and add corresponding constructors. > For convenience, perhaps also add a utility class that wraps a ByteBuffer > and/or byte[] and implements the new interface. > (The sevenz package appears to have a similar limitation, so it might make > sense to add the support there at the same time, but I personally don't have > a need for that.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COMPRESS-327) Support in-memory processing for ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic updated COMPRESS-327: -- Attachment: 0001-Add-a-SeekableInputStream-and-some-subclasses-that-Z.patch Sorry. Here is the patch with all the files. > Support in-memory processing for ZipFile > > > Key: COMPRESS-327 > URL: https://issues.apache.org/jira/browse/COMPRESS-327 > Project: Commons Compress > Issue Type: New Feature >Reporter: Brett Kail >Priority: Minor > Attachments: > 0001-Add-a-SeekableInputStream-and-some-subclasses-that-Z.patch, > seekable-input-stream.txt > > > ZipFile (and SevenZFile) currently require a File argument, but it would be > nice to support in-memory byte buffers rather than requiring temp files. > Perhaps create a new SeekableInputStream class (or SeekableDataInput > interface) and add corresponding constructors. > For convenience, perhaps also add a utility class that wraps a ByteBuffer > and/or byte[] and implements the new interface. > (The sevenz package appears to have a similar limitation, so it might make > sense to add the support there at the same time, but I personally don't have > a need for that.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DAEMON-341) prunsrv injects garbage into ImagePath
[ https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Dobrinin updated DAEMON-341: Environment: Windows Server 2008 (not R2) (was: Windows Server 2008) > prunsrv injects garbage into ImagePath > -- > > Key: DAEMON-341 > URL: https://issues.apache.org/jira/browse/DAEMON-341 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows Server 2008 (not R2) >Reporter: Mikhail Dobrinin > > Here is a reproducible example that works every time: > {noformat} > prunsrv.exe //IS//abcd.branch2 --StartMode=jvm > --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass > --StartMethod=startService ++StartParams=abcd.branch2 > {noformat} > The ImagePath entry for the service ends up being: > {noformat} > C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 > {noformat} > As you see, there is garbage inserted in front of the {{//RS//}} string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DAEMON-341) prunsrv injects garbage into ImagePath
[ https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047599#comment-15047599 ] Mikhail Dobrinin commented on DAEMON-341: - No, I skimmed the code but nothing stood out to me. I can't reproduce this on other OSes, so this may be related to Server 2008 somehow. > prunsrv injects garbage into ImagePath > -- > > Key: DAEMON-341 > URL: https://issues.apache.org/jira/browse/DAEMON-341 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows Server 2008 >Reporter: Mikhail Dobrinin > > Here is a reproducible example that works every time: > {noformat} > prunsrv.exe //IS//abcd.branch2 --StartMode=jvm > --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass > --StartMethod=startService ++StartParams=abcd.branch2 > {noformat} > The ImagePath entry for the service ends up being: > {noformat} > C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 > {noformat} > As you see, there is garbage inserted in front of the {{//RS//}} string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DAEMON-341) prunsrv injects garbage into ImagePath
[ https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047542#comment-15047542 ] Gary Gregory commented on DAEMON-341: - Yuk, do you have a patch perchance? > prunsrv injects garbage into ImagePath > -- > > Key: DAEMON-341 > URL: https://issues.apache.org/jira/browse/DAEMON-341 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows Server 2008 >Reporter: Mikhail Dobrinin > > Here is a reproducible example that works every time: > {noformat} > prunsrv.exe //IS//abcd.branch2 --StartMode=jvm > --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass > --StartMethod=startService ++StartParams=abcd.branch2 > {noformat} > The ImagePath entry for the service ends up being: > {noformat} > C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 > {noformat} > As you see, there is garbage inserted in front of the {{//RS//}} string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DAEMON-341) prunsrv injects garbage into ImagePath
[ https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Dobrinin updated DAEMON-341: Priority: Major (was: Blocker) > prunsrv injects garbage into ImagePath > -- > > Key: DAEMON-341 > URL: https://issues.apache.org/jira/browse/DAEMON-341 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows Server 2008 >Reporter: Mikhail Dobrinin > > Here is a reproducible example that works every time: > {noformat} > prunsrv.exe //IS//abcd.branch2 --StartMode=jvm > --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass > --StartMethod=startService ++StartParams=abcd.branch2 > {noformat} > The ImagePath entry for the service ends up being: > {noformat} > C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 > {noformat} > As you see, there is garbage inserted in front of the {{//RS//}} string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DAEMON-341) prunsrv injects garbage into ImageData
[ https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Dobrinin updated DAEMON-341: Priority: Blocker (was: Major) > prunsrv injects garbage into ImageData > -- > > Key: DAEMON-341 > URL: https://issues.apache.org/jira/browse/DAEMON-341 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows Server 2008 >Reporter: Mikhail Dobrinin >Priority: Blocker > > Here is a reproducible example that works every time: > {noformat} > prunsrv.exe //IS//abcd.branch2 --StartMode=jvm > --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass > --StartMethod=startService ++StartParams=abcd.branch2 > {noformat} > The ImageData entry for the service ends up being: > {noformat} > C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 > {noformat} > As you see, there is garbage inserted in front of the {{//RS//}} string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DAEMON-341) prunsrv injects garbage into ImagePath
[ https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Dobrinin updated DAEMON-341: Summary: prunsrv injects garbage into ImagePath (was: prunsrv injects garbage into ImageData) > prunsrv injects garbage into ImagePath > -- > > Key: DAEMON-341 > URL: https://issues.apache.org/jira/browse/DAEMON-341 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows Server 2008 >Reporter: Mikhail Dobrinin >Priority: Blocker > > Here is a reproducible example that works every time: > {noformat} > prunsrv.exe //IS//abcd.branch2 --StartMode=jvm > --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass > --StartMethod=startService ++StartParams=abcd.branch2 > {noformat} > The ImageData entry for the service ends up being: > {noformat} > C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 > {noformat} > As you see, there is garbage inserted in front of the {{//RS//}} string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DAEMON-341) prunsrv injects garbage into ImagePath
[ https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Dobrinin updated DAEMON-341: Description: Here is a reproducible example that works every time: {noformat} prunsrv.exe //IS//abcd.branch2 --StartMode=jvm --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass --StartMethod=startService ++StartParams=abcd.branch2 {noformat} The ImagePath entry for the service ends up being: {noformat} C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 {noformat} As you see, there is garbage inserted in front of the {{//RS//}} string. was: Here is a reproducible example that works every time: {noformat} prunsrv.exe //IS//abcd.branch2 --StartMode=jvm --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass --StartMethod=startService ++StartParams=abcd.branch2 {noformat} The ImageData entry for the service ends up being: {noformat} C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 {noformat} As you see, there is garbage inserted in front of the {{//RS//}} string. > prunsrv injects garbage into ImagePath > -- > > Key: DAEMON-341 > URL: https://issues.apache.org/jira/browse/DAEMON-341 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows Server 2008 >Reporter: Mikhail Dobrinin >Priority: Blocker > > Here is a reproducible example that works every time: > {noformat} > prunsrv.exe //IS//abcd.branch2 --StartMode=jvm > --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass > --StartMethod=startService ++StartParams=abcd.branch2 > {noformat} > The ImagePath entry for the service ends up being: > {noformat} > C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 > {noformat} > As you see, there is garbage inserted in front of the {{//RS//}} string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DAEMON-341) prunsrv injects garbage into ImageData
Mikhail Dobrinin created DAEMON-341: --- Summary: prunsrv injects garbage into ImageData Key: DAEMON-341 URL: https://issues.apache.org/jira/browse/DAEMON-341 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.15 Environment: Windows Server 2008 Reporter: Mikhail Dobrinin Here is a reproducible example that works every time: {noformat} prunsrv.exe //IS//abcd.branch2 --StartMode=jvm --StartClass=abc.abcdefghih.abcd.abcdef.abcd.MyImportantClass --StartMethod=startService ++StartParams=abcd.branch2 {noformat} The ImageData entry for the service ends up being: {noformat} C:\path\to\prunsrv.exe 12-08.loɥ//RS//abcd.branch2 {noformat} As you see, there is garbage inserted in front of the {{//RS//}} string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JXPATH-187) Possible endless loop in Namespace Resolving
[ https://issues.apache.org/jira/browse/JXPATH-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047117#comment-15047117 ] Michele Vivoda commented on JXPATH-187: --- Hi, this to me looks already fixed by JXPATH-140, your tests passed on my machine, without the patch. https://github.com/apache/commons-jxpath/blob/trunk/src/main/java/org/apache/commons/jxpath/ri/NamespaceResolver.java#L66 Please try the current trunk (that has many other bug fix) downloading the source from github https://github.com/apache/commons-jxpath > Possible endless loop in Namespace Resolving > > > Key: JXPATH-187 > URL: https://issues.apache.org/jira/browse/JXPATH-187 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Stefan Albrecht > Attachments: patch.junit.tgz, patch.txt > > > When dealing with XML documents - org.w3c.dom - and when having a hierarchy > of relative contexts, then, when trying to resolve the namespace prefix for > some namespace uri, an endless loop is triggered. > This happens if > * the namespace is not programatically registered with JXPathContext > * the context used to resolve the namespace > ** has a parent context > ** and neither the context nor the parent have the namespace defined within > the document > I attached a patch for org/apache/commons/jxpath/ri/NamespaceResolver.java > as well as a tar ball with a junit test and test files -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-327) Support in-memory processing for ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047045#comment-15047045 ] Stefan Bodewig commented on COMPRESS-327: - It took me way longer than I expected, sorry about that. Before I start making noise on the dev list, [~damjan] does your code actually require Java7? Neither your patch here, nor the one sent to the dev list contain the Seekable*Stream classes themselves. > Support in-memory processing for ZipFile > > > Key: COMPRESS-327 > URL: https://issues.apache.org/jira/browse/COMPRESS-327 > Project: Commons Compress > Issue Type: New Feature >Reporter: Brett Kail >Priority: Minor > Attachments: seekable-input-stream.txt > > > ZipFile (and SevenZFile) currently require a File argument, but it would be > nice to support in-memory byte buffers rather than requiring temp files. > Perhaps create a new SeekableInputStream class (or SeekableDataInput > interface) and add corresponding constructors. > For convenience, perhaps also add a utility class that wraps a ByteBuffer > and/or byte[] and implements the new interface. > (The sevenz package appears to have a similar limitation, so it might make > sense to add the support there at the same time, but I personally don't have > a need for that.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JXPATH-187) Possible endless loop in Namespace Resolving
[ https://issues.apache.org/jira/browse/JXPATH-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Albrecht updated JXPATH-187: --- Attachment: patch.txt patch.junit.tgz > Possible endless loop in Namespace Resolving > > > Key: JXPATH-187 > URL: https://issues.apache.org/jira/browse/JXPATH-187 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Stefan Albrecht > Attachments: patch.junit.tgz, patch.txt > > > When dealing with XML documents - org.w3c.dom - and when having a hierarchy > of relative contexts, then, when trying to resolve the namespace prefix for > some namespace uri, an endless loop is triggered. > This happens if > * the namespace is not programatically registered with JXPathContext > * the context used to resolve the namespace > ** has a parent context > ** and neither the context nor the parent have the namespace defined within > the document > I attached a patch for org/apache/commons/jxpath/ri/NamespaceResolver.java > as well as a tar ball with a junit test and test files -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JXPATH-187) Possible endless loop in Namespace Resolving
Stefan Albrecht created JXPATH-187: -- Summary: Possible endless loop in Namespace Resolving Key: JXPATH-187 URL: https://issues.apache.org/jira/browse/JXPATH-187 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.3 Reporter: Stefan Albrecht When dealing with XML documents - org.w3c.dom - and when having a hierarchy of relative contexts, then, when trying to resolve the namespace prefix for some namespace uri, an endless loop is triggered. This happens if * the namespace is not programatically registered with JXPathContext * the context used to resolve the namespace ** has a parent context ** and neither the context nor the parent have the namespace defined within the document I attached a patch for org/apache/commons/jxpath/ri/NamespaceResolver.java as well as a tar ball with a junit test and test files -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VALIDATOR-384) EmailValidator does not support escaped quotes in a quoted string
[ https://issues.apache.org/jira/browse/VALIDATOR-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kris Babic updated VALIDATOR-384: - Priority: Major (was: Minor) > EmailValidator does not support escaped quotes in a quoted string > - > > Key: VALIDATOR-384 > URL: https://issues.apache.org/jira/browse/VALIDATOR-384 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.4.1 Release >Reporter: Kris Babic > Attachments: VALIDATOR-384.patch > > > EmailValidator does not support escaped quotes '\"' within a quoted string as > specified by [RFC5322 section > 3.2.4|https://tools.ietf.org/html/rfc5322#page-13] as well as in the older > [RFC2822 section 3.2.5|https://tools.ietf.org/html/rfc2822#page-13]. > These sections indicate that a quoted string can contain a quoted pair > (escaped characters), where a quoted pair is defined as (in RFC5322): > {quote} >quoted-pair = ("\" (VCHAR / WSP)) / obs-qp >VCHAR = %x21-7E; visible (printing) characters > {quote} > The " character is %x22 which falls under the definition of VCHAR above. > Examples: > {quote} > "example\"email"@example.org > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VALIDATOR-384) EmailValidator does not support escaped quotes in a quoted string
[ https://issues.apache.org/jira/browse/VALIDATOR-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kris Babic updated VALIDATOR-384: - Attachment: VALIDATOR-384.patch Patch which updates the QUOTED_USER regular expression to allow for an escaped quote '\"' to be contained within the quoted string component of the local address. > EmailValidator does not support escaped quotes in a quoted string > - > > Key: VALIDATOR-384 > URL: https://issues.apache.org/jira/browse/VALIDATOR-384 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.4.1 Release >Reporter: Kris Babic >Priority: Minor > Attachments: VALIDATOR-384.patch > > > EmailValidator does not support escaped quotes '\"' within a quoted string as > specified by [RFC5322 section > 3.2.4|https://tools.ietf.org/html/rfc5322#page-13] as well as in the older > [RFC2822 section 3.2.5|https://tools.ietf.org/html/rfc2822#page-13]. > These sections indicate that a quoted string can contain a quoted pair > (escaped characters), where a quoted pair is defined as (in RFC5322): > {quote} >quoted-pair = ("\" (VCHAR / WSP)) / obs-qp >VCHAR = %x21-7E; visible (printing) characters > {quote} > The " character is %x22 which falls under the definition of VCHAR above. > Examples: > {quote} > "example\"email"@example.org > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VALIDATOR-384) EmailValidator does not support escaped quotes in a quoted string
Kris Babic created VALIDATOR-384: Summary: EmailValidator does not support escaped quotes in a quoted string Key: VALIDATOR-384 URL: https://issues.apache.org/jira/browse/VALIDATOR-384 Project: Commons Validator Issue Type: Bug Components: Routines Affects Versions: 1.4.1 Release Reporter: Kris Babic Priority: Minor EmailValidator does not support escaped quotes '\"' within a quoted string as specified by [RFC5322 section 3.2.4|https://tools.ietf.org/html/rfc5322#page-13] as well as in the older [RFC2822 section 3.2.5|https://tools.ietf.org/html/rfc2822#page-13]. These sections indicate that a quoted string can contain a quoted pair (escaped characters), where a quoted pair is defined as (in RFC5322): {quote} quoted-pair = ("\" (VCHAR / WSP)) / obs-qp VCHAR = %x21-7E; visible (printing) characters {quote} The " character is %x22 which falls under the definition of VCHAR above. Examples: {quote} "example\"email"@example.org {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JEXL-153) javadoc fails with 1.8.0
[ https://issues.apache.org/jira/browse/JEXL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg updated JEXL-153: Fix Version/s: 3.0 > javadoc fails with 1.8.0 > > > Key: JEXL-153 > URL: https://issues.apache.org/jira/browse/JEXL-153 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Fedora w/ OpenJDK 1.8.0 >Reporter: Orion Poplawski >Priority: Minor > Labels: javadoc > Fix For: 3.0 > > Attachments: apache-commons-jexl-javadoc.patch > > > OpenJDK 1.8.0's javadoc is much more strict about HTML usage in javadoc. The > attached patch fixes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JEXL-158) Handle locale decimal separators correctly
[ https://issues.apache.org/jira/browse/JEXL-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg updated JEXL-158: Fix Version/s: 3.0 > Handle locale decimal separators correctly > -- > > Key: JEXL-158 > URL: https://issues.apache.org/jira/browse/JEXL-158 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.0 > Environment: Debian Jessie 8.1 64 Bit > Maven 3.0.5-3 > OpenJDK 7u79-2.5.5-1~deb8u1 > German language >Reporter: Lars Cebulla >Priority: Blocker > Fix For: 3.0 > > > Hi, > running ArithmeticTest in a German environment, the methods > testBigLiteralValue and testBigLiterals fail. > testBigLiteralValue's Exception: > java.lang.RuntimeException: check parse failed: 9223372036854775806,5b > / */ 9223372036854775806.5B > at org.apache.commons.jexl3.internal.Util.debuggerCheck(Util.java:72) > at > org.apache.commons.jexl3.JexlTestCase.debuggerCheck(JexlTestCase.java:71) > at org.apache.commons.jexl3.JexlTestCase.tearDown(JexlTestCase.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: org.apache.commons.jexl3.JexlException$Parsing: > sun.reflect.NativeMethodAccessorImpl.invoke0@1:20 parsing error in ',' > ... 25 more > testBigLiterals' Exception: > java.lang.RuntimeException: check parse failed: { > a = 10h; > b = 10h; > c = 42,0b; > d = 42,0b; > } / */ {a = 10H; b = 10h; c = 42.0B; d = 42.0b;} > at org.apache.commons.jexl3.internal.Util.debuggerCheck(Util.java:72) > at > org.apache.commons.jexl3.JexlTestCase.debuggerCheck(JexlTestCase.java:71) > at org.apache.commons.jexl3.JexlTestCase.tearDown(JexlTestCase.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runner
[jira] [Created] (LANG-1191) Incorrect javadoc
qed created LANG-1191: - Summary: Incorrect javadoc Key: LANG-1191 URL: https://issues.apache.org/jira/browse/LANG-1191 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.4 Reporter: qed Priority: Minor Javadoc for boolean org.apache.commons.lang3.StringUtils.containsAny(CharSequence cs, CharSequence... searchCharSequences) says: StringUtils.containsAny("abcd", "ab", "cd") = false which is not true. It should be: StringUtils.containsAny("abcd", "ab", "cd") = true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[ https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046623#comment-15046623 ] Joerg Schaible edited comment on COLLECTIONS-580 at 12/8/15 11:16 AM: -- THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list! (Note, this was a reply to a comment that have been deleted afterwards by its original author). was (Author: joehni): THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list! > Arbitrary remote code execution with InvokerTransformer > --- > > Key: COLLECTIONS-580 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-580 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.0, 4.0 >Reporter: Philippe Marschall > Fix For: 3.2.2, 4.1 > > Attachments: COLLECTIONS-580.patch > > > With {{InvokerTransformer}} serializable collections can be build that > execute arbitrary Java code. > {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes > {{#entrySet}} and {{#get}} on a deserialized collection. If you have an > endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you > can combine the two to create arbitrary remote code execution vulnerability. > I don't know of a good fix short of removing {{InvokerTransformer}} or making > it not Serializable. Both probably break existing applications. > This is not my research, but has been discovered by other people. > https://github.com/frohoff/ysoserial > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[ https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046623#comment-15046623 ] Joerg Schaible edited comment on COLLECTIONS-580 at 12/8/15 11:16 AM: -- THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list! (Note, this was a reply to a comment that has been deleted afterwards by its original author). was (Author: joehni): THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list! (Note, this was a reply to a comment that have been deleted afterwards by its original author). > Arbitrary remote code execution with InvokerTransformer > --- > > Key: COLLECTIONS-580 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-580 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.0, 4.0 >Reporter: Philippe Marschall > Fix For: 3.2.2, 4.1 > > Attachments: COLLECTIONS-580.patch > > > With {{InvokerTransformer}} serializable collections can be build that > execute arbitrary Java code. > {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes > {{#entrySet}} and {{#get}} on a deserialized collection. If you have an > endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you > can combine the two to create arbitrary remote code execution vulnerability. > I don't know of a good fix short of removing {{InvokerTransformer}} or making > it not Serializable. Both probably break existing applications. > This is not my research, but has been discovered by other people. > https://github.com/frohoff/ysoserial > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[ https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] meiyoula updated COLLECTIONS-580: - Comment: was deleted (was: Hi, all. Let me ask a low question, the jar file which corresponding this source is describe as {quote} commons-collections commons-collections 3.2.2 {quote} or {quote} org.apache.commons commons-collections 3.2.2 {quote} ) > Arbitrary remote code execution with InvokerTransformer > --- > > Key: COLLECTIONS-580 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-580 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.0, 4.0 >Reporter: Philippe Marschall > Fix For: 3.2.2, 4.1 > > Attachments: COLLECTIONS-580.patch > > > With {{InvokerTransformer}} serializable collections can be build that > execute arbitrary Java code. > {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes > {{#entrySet}} and {{#get}} on a deserialized collection. If you have an > endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you > can combine the two to create arbitrary remote code execution vulnerability. > I don't know of a good fix short of removing {{InvokerTransformer}} or making > it not Serializable. Both probably break existing applications. > This is not my research, but has been discovered by other people. > https://github.com/frohoff/ysoserial > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[ https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046623#comment-15046623 ] Joerg Schaible commented on COLLECTIONS-580: THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list! > Arbitrary remote code execution with InvokerTransformer > --- > > Key: COLLECTIONS-580 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-580 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.0, 4.0 >Reporter: Philippe Marschall > Fix For: 3.2.2, 4.1 > > Attachments: COLLECTIONS-580.patch > > > With {{InvokerTransformer}} serializable collections can be build that > execute arbitrary Java code. > {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes > {{#entrySet}} and {{#get}} on a deserialized collection. If you have an > endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you > can combine the two to create arbitrary remote code execution vulnerability. > I don't know of a good fix short of removing {{InvokerTransformer}} or making > it not Serializable. Both probably break existing applications. > This is not my research, but has been discovered by other people. > https://github.com/frohoff/ysoserial > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[ https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046603#comment-15046603 ] meiyoula commented on COLLECTIONS-580: -- Hi, all. Let me ask a low question, the jar file which corresponding this source is describe as {quote} commons-collections commons-collections 3.2.2 {quote} or {quote} org.apache.commons commons-collections 3.2.2 {quote} > Arbitrary remote code execution with InvokerTransformer > --- > > Key: COLLECTIONS-580 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-580 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.0, 4.0 >Reporter: Philippe Marschall > Fix For: 3.2.2, 4.1 > > Attachments: COLLECTIONS-580.patch > > > With {{InvokerTransformer}} serializable collections can be build that > execute arbitrary Java code. > {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes > {{#entrySet}} and {{#get}} on a deserialized collection. If you have an > endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you > can combine the two to create arbitrary remote code execution vulnerability. > I don't know of a good fix short of removing {{InvokerTransformer}} or making > it not Serializable. Both probably break existing applications. > This is not my research, but has been discovered by other people. > https://github.com/frohoff/ysoserial > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)