[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=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=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)
[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=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] [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=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] [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] [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] [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] (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] (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] (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
[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] [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=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] [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=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] (DAEMON-341) prunsrv injects garbage into ImagePath
[
https://issues.apache.org/jira/browse/DAEMON-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [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] [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] [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=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 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] [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] [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] [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)
