from:"Manuel Shenavai \(Jira\)"

[jira] [Created] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-05-03 Thread Manuel Shenavai (Jira)

Manuel Shenavai created CXF-8698:


 Summary: Content-ID of attachments for outgoing requests are 
URL-decoded instead of URL-encoded
 Key: CXF-8698
 URL: https://issues.apache.org/jira/browse/CXF-8698
 Project: CXF
  Issue Type: Bug
  Components: Transports
Affects Versions: 3.5.1, 3.2.11
Reporter: Manuel Shenavai


We are using camel CXF and we found that for an outgoing request, the 
Content-ID header of attachments is URL-decoded. We can also see that the 
Content-ID of incoming requests is also URL-decoded. I would expect that for 
outgoing requests, the Content-ID would get URL-encoded.

Code: 
[https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]

Stacktrace:

"main@1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at 
org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
 at 
org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
 at 
org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
 at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
 - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain) at 
org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532) at 
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441) at 
org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170) at 
org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
 at 
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
 at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148) at 
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
 at 
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
 at org.apache.camel.processor.Pipeline.process(Pipeline.java:138) at 
org.apache.camel.processor.Pipeline.process(Pipeline.java:101) at 
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
 at 
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
 at 
org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
 at 
org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
 at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541) 
at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506) 
at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369) at 
org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506) at 
org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229) at 
org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
 at 
org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
 at 
org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
 at soap12.Client.sendMessage(Client.java:24) at 
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) 
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498) at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
 at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
 at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
 at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
 at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) at 
org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) at 
org.junit.rules.RunRules.evaluate(RunRules.java:20) at 
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
 at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at 
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at 
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at 
org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at 
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at 
org.junit.runners.ParentRunner.run(ParentRunner.java:363) at 
org

[jira] [Updated] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-05-03 Thread Manuel Shenavai (Jira)



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

Manuel Shenavai updated CXF-8698:
-
Description: 
We are using camel CXF and we found that for an outgoing request, the 
Content-ID header of attachments is URL-decoded. We can also see that the 
Content-ID of incoming requests is also URL-decoded. I would expect that for 
outgoing requests, the Content-ID would get URL-encoded.

Code: 
[https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]

Stacktrace:

"main@1" prio=5 tid=0x1 nid=NA runnable
  java.lang.Thread.State: RUNNABLE
   at 
org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
   at 
org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
   at 
org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
   at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
   - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
   at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
   at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
   at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
   at 
org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
   at 
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
   at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
   at 
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
   at 
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
   at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
   at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
   at 
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
   at 
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
   at 
org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
   at 
org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
   at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
   at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
   at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
   at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
   at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
   at 
org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
   at 
org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
   at 
org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
   at soap12.Client.sendMessage(Client.java:24)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
   at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
   at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
   at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
   at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
   at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
   at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
   at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
   at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(J

[jira] [Commented] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-05-03 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531379#comment-17531379
 ] 

Manuel Shenavai commented on CXF-8698:
--

We posted this on the mailinglist where Andriy proposed to create this ticket:
*Andriy Redko* - Tuesday, May 3, 2022 3:04:58 AM GMT+2
Hi Manuel,

Interesting, looking into RFC-2392, which says:

content-id = url-addr-spec
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec

Which basically confirms your observations, looks like a bug to me. Could you 
please
open an issue here [2]? Thank you.

[1] 
[https://datatracker.ietf.org/doc/html/rfc2392]
[2] 
[https://issues.apache.org/jira/projects/CXF/issues]
/

Best Regards,
Andriy Redko

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Priority: Major
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>    at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>    at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>    at 
> org.junit.internal.

[jira] [Commented] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-05-10 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534293#comment-17534293
 ] 

Manuel Shenavai commented on CXF-8698:
--

Can someone confirm that this is considered as a bug and that it will be fixed 
and what the timeline would be?

Thanks in advance
Manuel

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Priority: Major
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>    at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>    at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>    at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>    at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>    at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.RunRules.ev

[jira] [Commented] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-05-16 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537378#comment-17537378
 ] 

Manuel Shenavai commented on CXF-8698:
--

[~reta] thanks for looking into it. Our customer has a route through scenario 
where he is using something like *myattachm+ent.xml.* The customer expects that 
the outbound call contains the exact same content ID as the incoming message. 
But + is replace by whitespace, so the content ID changes to *myattachm 
ent.xml.*

Best regards,
Manuel

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Priority: Major
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>    at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>    at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>    at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>    at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>    at 
> org.junit.internal.runners.statements.Run

[jira] [Commented] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-05-24 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541315#comment-17541315
 ] 

Manuel Shenavai commented on CXF-8698:
--

Any update on this topic?

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Priority: Major
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>    at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>    at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>    at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>    at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>    at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>    at 
> org.ju

[jira] [Commented] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-06-30 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17561025#comment-17561025
 ] 

Manuel Shenavai commented on CXF-8698:
--

Hi Andriy,

this change is causing outgoing content-ids to be ENCODED. But unfortunately it 
also breaks the DECODE of incoming message. Content-ID headers do not contain 
"cid:-prefix as assumed here:
[{{{}221456a{}}}#diff-e3efb80d0a98bbbd7f6eddd3c021c5fb5ab05ea2ee8d97dc68026f6345e5a509R227|https://github.com/apache/cxf/commit/221456aa5a515589b3bcda07a879de1b6e5e458c#diff-e3efb80d0a98bbbd7f6eddd3c021c5fb5ab05ea2ee8d97dc68026f6345e5a509R227]

So after picking this change, I can see that outgoing headers are encoded but 
incoming messages are not decoded anymore. So I think there has to be a 
different condition to decide between en/decoding than the cid-prefix.

Can you check this again?

Best regards,
Manuel

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.3, 3.4.8, 4.0.0, 3.6.0
>
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.run

[jira] [Reopened] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-06-30 Thread Manuel Shenavai (Jira)



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

Manuel Shenavai reopened CXF-8698:
--

This change is breaking the decoding of the content-id for incoming messages

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.3, 3.4.8, 4.0.0, 3.6.0
>
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>    at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>    at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>    at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>    at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>    at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>

[jira] [Updated] (CXF-8729) Same endpoints with different SOAP versions dont work as expected

2022-07-04 Thread Manuel Shenavai (Jira)



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

Manuel Shenavai updated CXF-8729:
-
Priority: Critical  (was: Major)

> Same endpoints with different SOAP versions dont work as expected
> -
>
> Key: CXF-8729
> URL: https://issues.apache.org/jira/browse/CXF-8729
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Reporter: Manuel Shenavai
>Priority: Critical
>
> In Camel-CXF, endpoints with same URL but different SOAP version are possible 
> to start. Depending on the version of the SOAP message of the incoming 
> request, the corresponding endpoint will be invoked.
> But I found two problems:
> 1. Stopping a route that registered a specific endpoint URL (i.e. /myendpoint 
> for SOAP 1.1) will shutdown all endpoints of that URL (also /myendpoint with 
> SOAP 1.2 endpoint registered by different route)
> 2. There are some features (i.e. 
> CounterRepository<[https://github.com/apache/cxf/blob/master/rt/management/src/main/java/org/apache/cxf/management/counters/CounterRepository.java]>)
>  which seem to have problems with using sameURL/differentSOAP version. I 
> found they throw NullPointerException and return HTTP200 with an empty body. 
> I created a reproducer for both problems:
> [https://github.com/mash-sap/CXFEndpointsAndSOAPVersions]
> Referring to this mail chain:
> [https://www.mail-archive.com/users@cxf.apache.org/msg45320.html]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8729) Same endpoints with different SOAP versions dont work as expected

2022-07-04 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17562052#comment-17562052
 ] 

Manuel Shenavai commented on CXF-8729:
--

Increasing priority.

Had anyone a chance to have a look into this?

> Same endpoints with different SOAP versions dont work as expected
> -
>
> Key: CXF-8729
> URL: https://issues.apache.org/jira/browse/CXF-8729
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Reporter: Manuel Shenavai
>Priority: Critical
>
> In Camel-CXF, endpoints with same URL but different SOAP version are possible 
> to start. Depending on the version of the SOAP message of the incoming 
> request, the corresponding endpoint will be invoked.
> But I found two problems:
> 1. Stopping a route that registered a specific endpoint URL (i.e. /myendpoint 
> for SOAP 1.1) will shutdown all endpoints of that URL (also /myendpoint with 
> SOAP 1.2 endpoint registered by different route)
> 2. There are some features (i.e. 
> CounterRepository<[https://github.com/apache/cxf/blob/master/rt/management/src/main/java/org/apache/cxf/management/counters/CounterRepository.java]>)
>  which seem to have problems with using sameURL/differentSOAP version. I 
> found they throw NullPointerException and return HTTP200 with an empty body. 
> I created a reproducer for both problems:
> [https://github.com/mash-sap/CXFEndpointsAndSOAPVersions]
> Referring to this mail chain:
> [https://www.mail-archive.com/users@cxf.apache.org/msg45320.html]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8729) Same endpoints with different SOAP versions dont work as expected

2022-07-07 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563615#comment-17563615
 ] 

Manuel Shenavai commented on CXF-8729:
--

Hi [~ffang],

can you have a look into this? You also looked into a similar issue in the past 
(CXF-8533)

Best regards,
Manuel

> Same endpoints with different SOAP versions dont work as expected
> -
>
> Key: CXF-8729
> URL: https://issues.apache.org/jira/browse/CXF-8729
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Reporter: Manuel Shenavai
>Priority: Critical
>
> In Camel-CXF, endpoints with same URL but different SOAP version are possible 
> to start. Depending on the version of the SOAP message of the incoming 
> request, the corresponding endpoint will be invoked.
> But I found two problems:
> 1. Stopping a route that registered a specific endpoint URL (i.e. /myendpoint 
> for SOAP 1.1) will shutdown all endpoints of that URL (also /myendpoint with 
> SOAP 1.2 endpoint registered by different route)
> 2. There are some features (i.e. 
> CounterRepository<[https://github.com/apache/cxf/blob/master/rt/management/src/main/java/org/apache/cxf/management/counters/CounterRepository.java]>)
>  which seem to have problems with using sameURL/differentSOAP version. I 
> found they throw NullPointerException and return HTTP200 with an empty body. 
> I created a reproducer for both problems:
> [https://github.com/mash-sap/CXFEndpointsAndSOAPVersions]
> Referring to this mail chain:
> [https://www.mail-archive.com/users@cxf.apache.org/msg45320.html]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-07-12 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17566193#comment-17566193
 ] 

Manuel Shenavai commented on CXF-8698:
--

Hi, is there any update on this topic, [~reta] ?

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.3, 3.4.8, 4.0.0, 3.6.0
>
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>    at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>    at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>    at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>    at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>    at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.RunRules.eva

[jira] [Commented] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-08-01 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573765#comment-17573765
 ] 

Manuel Shenavai commented on CXF-8698:
--

Thanks [~reta] . I will pull the change into our fork and report back with the 
results soon.

Best regards,
Manuel

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.3, 3.4.8, 4.0.0, 3.6.0
>
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>    at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>    at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>    at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>    at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>    at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>    at org.junit.rules.TestWatcher$1

[jira] [Commented] (CXF-8698) Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded

2022-08-05 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17575873#comment-17575873
 ] 

Manuel Shenavai commented on CXF-8698:
--

Hi [~reta] . I can confirm that the filenames are now properly encoded/decoded. 
One thing I noticed and I'm not sure about the expected behavior is the 
following:
 # Filename in camel is Nice+FileName.txt, content-id header will be: 
Content-ID:   --> *OK*
 # Filename in camel is cid:Nice+Filename,txt, content-id header will be:   --> The filename was *decoded* instead of {*}encoded{*}. Is this 
the expected behavior?

> Content-ID of attachments for outgoing requests are URL-decoded instead of 
> URL-encoded
> --
>
> Key: CXF-8698
> URL: https://issues.apache.org/jira/browse/CXF-8698
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.2.11, 3.5.1
>Reporter: Manuel Shenavai
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.3, 3.4.8, 4.0.0, 3.6.0
>
>
> We are using camel CXF and we found that for an outgoing request, the 
> Content-ID header of attachments is URL-decoded. We can also see that the 
> Content-ID of incoming requests is also URL-decoded. I would expect that for 
> outgoing requests, the Content-ID would get URL-encoded.
> Code: 
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java#L218]
> Stacktrace:
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeHeaders(AttachmentSerializer.java:218)
>    at 
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog(AttachmentSerializer.java:182)
>    at 
> org.apache.cxf.interceptor.AttachmentOutInterceptor.handleMessage(AttachmentOutInterceptor.java:77)
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>    - locked <0x1538> (a org.apache.cxf.phase.PhaseInterceptorChain)
>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532)
>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
>    at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:170)
>    at 
> org.apache.camel.impl.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:62)
>    at 
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>    at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>    at 
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>    at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>    at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>    at 
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:76)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
>    at 
> org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
>    at 
> org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
>    at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
>    at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
>    at 
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:370)
>    at soap12.Client.sendMessage(Client.java:24)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>    at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.lang.reflect.Method.invoke(Method.java:498)
>    at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>    at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>    at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>    at 
> org.junit.internal.runners.statements.InvokeMethod.eval

[jira] [Commented] (CXF-8729) Same endpoints with different SOAP versions dont work as expected

2022-08-05 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17576003#comment-17576003
 ] 

Manuel Shenavai commented on CXF-8729:
--

Hi everyone,

in our case, it would be sufficient to disable the 
"soapversion-specific-endpoint"-feature of registering two endpoints with 
different SOAP versions. I created the following pull request that would allow 
users to disable the "soapversion-specific-endpoint"-feature via a system 
property:
[https://github.com/apache/cxf/pull/976]

Do you have any thoughts on this proposal?

Best regards,
Manuel

> Same endpoints with different SOAP versions dont work as expected
> -
>
> Key: CXF-8729
> URL: https://issues.apache.org/jira/browse/CXF-8729
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Reporter: Manuel Shenavai
>Priority: Critical
>
> In Camel-CXF, endpoints with same URL but different SOAP version are possible 
> to start. Depending on the version of the SOAP message of the incoming 
> request, the corresponding endpoint will be invoked.
> But I found two problems:
> 1. Stopping a route that registered a specific endpoint URL (i.e. /myendpoint 
> for SOAP 1.1) will shutdown all endpoints of that URL (also /myendpoint with 
> SOAP 1.2 endpoint registered by different route)
> 2. There are some features (i.e. 
> CounterRepository<[https://github.com/apache/cxf/blob/master/rt/management/src/main/java/org/apache/cxf/management/counters/CounterRepository.java]>)
>  which seem to have problems with using sameURL/differentSOAP version. I 
> found they throw NullPointerException and return HTTP200 with an empty body. 
> I created a reproducer for both problems:
> [https://github.com/mash-sap/CXFEndpointsAndSOAPVersions]
> Referring to this mail chain:
> [https://www.mail-archive.com/users@cxf.apache.org/msg45320.html]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-07 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17910642#comment-17910642
 ] 

Manuel Shenavai commented on CXF-9091:
--

Is there any update on this topic?

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-31 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922609#comment-17922609
 ] 

Manuel Shenavai commented on CXF-9091:
--

Hi [~ffang],

were you able to find the root cause of this problem? Do you already have any 
plans how this can be fixed?

Best regards,
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CXF-9104) Camel 3|CXF: Unspecific Parser Errors

2025-01-31 Thread Manuel Shenavai (Jira)

Manuel Shenavai created CXF-9104:


 Summary: Camel 3|CXF: Unspecific Parser Errors
 Key: CXF-9104
 URL: https://issues.apache.org/jira/browse/CXF-9104
 Project: CXF
  Issue Type: Bug
Reporter: Manuel Shenavai


With Camel3 and CXF 3.6, if a SOAP message exceeds i.e. 
-Dorg.apache.cxf.stax.maxAttributeSize, this leads to an unspecific parser 
error (see below)

Expected behavior: The messages should fail with "XMLStreamException:Maximum 
attribute size limit (65536) exceeded" (This is how it worked in Camel2/CXF3.2)

Reproducer: 
https://github.com/mash-sap/cxfOneWayError/tree/maxAttributeSizeParserError

Stacktrace
---

org.apache.camel.TypeConversionException: Error during type conversion from 
type: org.apache.camel.component.cxf.converter.CachedCxfPayload to the required 
type: java.lang.String with value 
org.apache.camel.component.cxf.converter.CachedCxfPayload@3210564b due to 
java.lang.IllegalStateException: Current event not START_ELEMENT or END_ELEMENT
at 
org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:105)
 ~[camel-support-3.17.0.jar:3.17.0]
at 
org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:519)
 ~[camel-base-3.17.0.jar:3.17.0]
at 
org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
 ~[camel-base-3.17.0.jar:3.17.0]
at 
org.apache.camel.impl.converter.CoreTypeConverterRegistry.convertTo(CoreTypeConverterRegistry.java:202)
 ~[camel-base-3.17.0.jar:3.17.0]
at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:96) 
~[camel-support-3.17.0.jar:3.17.0]
at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:72) 
~[camel-support-3.17.0.jar:3.17.0]
at de.mash.demo.MyProcessor.process(MyProcessor.java:14) ~[classes/:na]
at 
org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:65)
 ~[camel-support-3.17.0.jar:3.17.0]
at 
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:471)
 ~[camel-core-processor-3.17.0.jar:3.17.0]
at 
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:189)
 ~[camel-base-engine-3.17.0.jar:3.17.0]
at 
org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:61)
 ~[camel-base-engine-3.17.0.jar:3.17.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:184) 
~[camel-core-processor-3.17.0.jar:3.17.0]
at 
org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:399)
 ~[camel-base-engine-3.17.0.jar:3.17.0]
at 
org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
 ~[camel-base-engine-3.17.0.jar:3.17.0]
at 
org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41)
 ~[camel-support-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:240)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
 ~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
 ~[cxf-rt-transports-http-3.6.5.jar:3.6.5]
at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
 ~[cxf-rt-transports-http-3.6.5.jar:3.6.5]
at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
 ~[cxf-rt-transports-http-3.6.5.jar:3.6.5]
at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
 ~[cxf-rt-transports-http-3.6.5.jar:3.6.5]
at 
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServl

[jira] [Commented] (CXF-9104) Camel 3|CXF: Unspecific Parser Errors

2025-01-31 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922725#comment-17922725
 ] 

Manuel Shenavai commented on CXF-9104:
--

Thanks for checking this, [~ffang].

I think the problem may be related to the payload from the readme. You need to 
take the code-format not from "preview"-format. With this payload its 
reproducible:

http://schemas.xmlsoap.org/soap/envelope/";>


http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://test.de/4.0/billing/acc";
xmlns:ns2="http://test.de/1.0/customer-services/billing/importAccounting";>







> Camel 3|CXF: Unspecific Parser Errors
> -
>
> Key: CXF-9104
> URL: https://issues.apache.org/jira/browse/CXF-9104
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> With Camel3 and CXF 3.6, if a SOAP message exceeds i.e. 
> -Dorg.apache.cxf.stax.maxAttributeSize, this leads to an unspecific parser 
> error (see below)
> Expected behavior: The messages should fail with "XMLStreamException:Maximum 
> attribute size limit (65536) exceeded" (This is how it worked in 
> Camel2/CXF3.2)
> Reproducer: 
> https://github.com/mash-sap/cxfOneWayError/tree/maxAttributeSizeParserError
> Stacktrace
> ---
> org.apache.camel.TypeConversionException: Error during type conversion from 
> type: org.apache.camel.component.cxf.converter.CachedCxfPayload to the 
> required type: java.lang.String with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@3210564b due to 
> java.lang.IllegalStateException: Current event not START_ELEMENT or 
> END_ELEMENT
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:105)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:519)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.convertTo(CoreTypeConverterRegistry.java:202)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:96) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:72) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at de.mash.demo.MyProcessor.process(MyProcessor.java:14) ~[classes/:na]
> at 
> org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:65)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:471)
>  ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:189)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:61)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:184) 
> ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:399)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:240)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
>  ~[na:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(Phas

[jira] [Comment Edited] (CXF-9104) Camel 3|CXF: Unspecific Parser Errors

2025-02-04 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923807#comment-17923807
 ] 

Manuel Shenavai edited comment on CXF-9104 at 2/4/25 7:10 PM:
--

Thanks for looking into this, [~ffang]! I found this change:
https://github.com/apache/camel/commit/23152a67d139db06710bd0bd82eb989a97002619

With this change the client would still not get the correct error ("Maximum 
attribute size limit (65536) exceeded") and it correct error would only be 
logged on debug log level. This will not resolve the problem or am I missing 
something?


was (Author: mash-sap):
Thanks for looking into this[~ffang]! I found this change:
https://github.com/apache/camel/commit/23152a67d139db06710bd0bd82eb989a97002619

With this change the client would still not get the correct error ("Maximum 
attribute size limit (65536) exceeded") and it correct error would only be 
logged on debug log level. This will not resolve the problem or am I missing 
something?

> Camel 3|CXF: Unspecific Parser Errors
> -
>
> Key: CXF-9104
> URL: https://issues.apache.org/jira/browse/CXF-9104
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
>
> With Camel3 and CXF 3.6, if a SOAP message exceeds i.e. 
> -Dorg.apache.cxf.stax.maxAttributeSize, this leads to an unspecific parser 
> error (see below)
> Expected behavior: The messages should fail with "XMLStreamException:Maximum 
> attribute size limit (65536) exceeded" (This is how it worked in 
> Camel2/CXF3.2)
> Reproducer: 
> https://github.com/mash-sap/cxfOneWayError/tree/maxAttributeSizeParserError
> Stacktrace
> ---
> org.apache.camel.TypeConversionException: Error during type conversion from 
> type: org.apache.camel.component.cxf.converter.CachedCxfPayload to the 
> required type: java.lang.String with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@3210564b due to 
> java.lang.IllegalStateException: Current event not START_ELEMENT or 
> END_ELEMENT
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:105)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:519)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.convertTo(CoreTypeConverterRegistry.java:202)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:96) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:72) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at de.mash.demo.MyProcessor.process(MyProcessor.java:14) ~[classes/:na]
> at 
> org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:65)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:471)
>  ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:189)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:61)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:184) 
> ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:399)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:240)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
>  ~[na:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
> at

[jira] [Commented] (CXF-9104) Camel 3|CXF: Unspecific Parser Errors

2025-02-04 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923807#comment-17923807
 ] 

Manuel Shenavai commented on CXF-9104:
--

Thanks for looking into this[~ffang]! I found this change:
https://github.com/apache/camel/commit/23152a67d139db06710bd0bd82eb989a97002619

With this change the client would still not get the correct error ("Maximum 
attribute size limit (65536) exceeded") and it correct error would only be 
logged on debug log level. This will not resolve the problem or am I missing 
something?

> Camel 3|CXF: Unspecific Parser Errors
> -
>
> Key: CXF-9104
> URL: https://issues.apache.org/jira/browse/CXF-9104
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
>
> With Camel3 and CXF 3.6, if a SOAP message exceeds i.e. 
> -Dorg.apache.cxf.stax.maxAttributeSize, this leads to an unspecific parser 
> error (see below)
> Expected behavior: The messages should fail with "XMLStreamException:Maximum 
> attribute size limit (65536) exceeded" (This is how it worked in 
> Camel2/CXF3.2)
> Reproducer: 
> https://github.com/mash-sap/cxfOneWayError/tree/maxAttributeSizeParserError
> Stacktrace
> ---
> org.apache.camel.TypeConversionException: Error during type conversion from 
> type: org.apache.camel.component.cxf.converter.CachedCxfPayload to the 
> required type: java.lang.String with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@3210564b due to 
> java.lang.IllegalStateException: Current event not START_ELEMENT or 
> END_ELEMENT
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:105)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:519)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.convertTo(CoreTypeConverterRegistry.java:202)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:96) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:72) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at de.mash.demo.MyProcessor.process(MyProcessor.java:14) ~[classes/:na]
> at 
> org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:65)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:471)
>  ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:189)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:61)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:184) 
> ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:399)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:240)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
>  ~[na:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(Ph

[jira] [Comment Edited] (CXF-9104) Camel 3|CXF: Unspecific Parser Errors

2025-02-04 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923807#comment-17923807
 ] 

Manuel Shenavai edited comment on CXF-9104 at 2/4/25 7:10 PM:
--

Thanks for looking into this, [~ffang]! I found this change:
https://github.com/apache/camel/commit/23152a67d139db06710bd0bd82eb989a97002619

With this change the client would still not get the correct error ("Maximum 
attribute size limit (65536) exceeded") and the correct error would only be 
logged on debug log level. This will not resolve the problem or am I missing 
something?


was (Author: mash-sap):
Thanks for looking into this, [~ffang]! I found this change:
https://github.com/apache/camel/commit/23152a67d139db06710bd0bd82eb989a97002619

With this change the client would still not get the correct error ("Maximum 
attribute size limit (65536) exceeded") and it correct error would only be 
logged on debug log level. This will not resolve the problem or am I missing 
something?

> Camel 3|CXF: Unspecific Parser Errors
> -
>
> Key: CXF-9104
> URL: https://issues.apache.org/jira/browse/CXF-9104
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
>
> With Camel3 and CXF 3.6, if a SOAP message exceeds i.e. 
> -Dorg.apache.cxf.stax.maxAttributeSize, this leads to an unspecific parser 
> error (see below)
> Expected behavior: The messages should fail with "XMLStreamException:Maximum 
> attribute size limit (65536) exceeded" (This is how it worked in 
> Camel2/CXF3.2)
> Reproducer: 
> https://github.com/mash-sap/cxfOneWayError/tree/maxAttributeSizeParserError
> Stacktrace
> ---
> org.apache.camel.TypeConversionException: Error during type conversion from 
> type: org.apache.camel.component.cxf.converter.CachedCxfPayload to the 
> required type: java.lang.String with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@3210564b due to 
> java.lang.IllegalStateException: Current event not START_ELEMENT or 
> END_ELEMENT
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:105)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:519)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.convertTo(CoreTypeConverterRegistry.java:202)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:96) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:72) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at de.mash.demo.MyProcessor.process(MyProcessor.java:14) ~[classes/:na]
> at 
> org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:65)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:471)
>  ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:189)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:61)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:184) 
> ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:399)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:240)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
>  ~[na:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
>

[jira] [Comment Edited] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-02-07 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925077#comment-17925077
 ] 

Manuel Shenavai edited comment on CXF-9091 at 2/7/25 11:05 PM:
---

Hi [~ffang], 

I found a possible fix for the problem. Can you please check my PR:
https://github.com/apache/cxf/pull/2261

Alternative solution:
https://github.com/apache/cxf/pull/2262

Thanks!
Manuel


was (Author: mash-sap):
Hi [~ffang], 

I found a possible fix for the problem. Can you please check my PR:
https://github.com/apache/cxf/pull/2261

Thanks!
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-02-07 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925077#comment-17925077
 ] 

Manuel Shenavai commented on CXF-9091:
--

Hi [~ffang], 

I found a possible fix for the problem. Can you please check my PR:
https://github.com/apache/cxf/pull/2261

Thanks!
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-02-10 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925598#comment-17925598
 ] 

Manuel Shenavai commented on CXF-9091:
--

Hi [~ffang], the interesting part is, that the rebase operation is already 
caching the request payload:
https://github.com/apache/cxf/blob/3.6.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/impl/InternalContextUtils.java#L276

But due to missing property (cxf.io.cacheinput) the inputStream is 
read/consumed here:
https://github.com/apache/cxf/blob/3.6.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java#L605
https://github.com/apache/cxf/blob/3.6.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java#L626

When eventually the workerThread tries to read the payload, the inputStreams 
position is already at the end which leads to the parser error. So the initial 
idea was to reset() the inputstream, which worked.

But I guess that using the property (cxf.io.cacheinput) is the correct way to 
let cxf know that this is a cached payload.

Best regards,
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-02-07 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17924819#comment-17924819
 ] 

Manuel Shenavai commented on CXF-9091:
--

Hi [~ffang], do you have any update on this topic?
Thanks in advance!
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9104) Camel 3|CXF: Unspecific Parser Errors

2025-02-07 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17924820#comment-17924820
 ] 

Manuel Shenavai commented on CXF-9104:
--

Thanks for the details, [~ffang]!

> Camel 3|CXF: Unspecific Parser Errors
> -
>
> Key: CXF-9104
> URL: https://issues.apache.org/jira/browse/CXF-9104
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
>
> With Camel3 and CXF 3.6, if a SOAP message exceeds i.e. 
> -Dorg.apache.cxf.stax.maxAttributeSize, this leads to an unspecific parser 
> error (see below)
> Expected behavior: The messages should fail with "XMLStreamException:Maximum 
> attribute size limit (65536) exceeded" (This is how it worked in 
> Camel2/CXF3.2)
> Reproducer: 
> https://github.com/mash-sap/cxfOneWayError/tree/maxAttributeSizeParserError
> Stacktrace
> ---
> org.apache.camel.TypeConversionException: Error during type conversion from 
> type: org.apache.camel.component.cxf.converter.CachedCxfPayload to the 
> required type: java.lang.String with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@3210564b due to 
> java.lang.IllegalStateException: Current event not START_ELEMENT or 
> END_ELEMENT
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:105)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:519)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.doConvertTo(CoreTypeConverterRegistry.java:358)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.converter.CoreTypeConverterRegistry.convertTo(CoreTypeConverterRegistry.java:202)
>  ~[camel-base-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:96) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at org.apache.camel.support.MessageSupport.getBody(MessageSupport.java:72) 
> ~[camel-support-3.17.0.jar:3.17.0]
> at de.mash.demo.MyProcessor.process(MyProcessor.java:14) ~[classes/:na]
> at 
> org.apache.camel.support.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:65)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:471)
>  ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:189)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:61)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:184) 
> ~[camel-core-processor-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:399)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
>  ~[camel-base-engine-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41)
>  ~[camel-support-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:240)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
>  ~[na:na]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  ~[cxf-core-3.6.5.jar:3.6.5]
> at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
>  ~[cxf-rt-transports-http-3.6.5.jar:3.6.5]
> at 
>

[jira] [Comment Edited] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2024-12-18 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906642#comment-17906642
 ] 

Manuel Shenavai edited comment on CXF-9091 at 12/18/24 8:10 AM:


One noteable observation:
Sending an incomplete payload which is expected to be not parseable, a HTTP 202 
returned in the new codeline. While on the old codeline this same request 
failed already in the HTTP thread, which led to HTTP 500 instead of HTTP 202.

In our old codeline, this is the stacktrace for a wrong XML. Client receives 
HTTP 500
Daemon Thread [https-jsse-nio-8041-exec-18]
org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:262)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getSOAPMessage(WSS4JInInterceptor.java:167)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:234)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:200)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:80)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:67)
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)...


The new codeline gets a HTTP 202.


was (Author: mash-sap):
One noteable observation:
Sending an incomplete payload which is expected to be not parseable, a HTTP 202 
returned in the new codeline. While on the old codeline this same request 
failed already in the HTTP thread, which led to HTTP 500 instead of HTTP 202.

In our old codeline, this is the stacktrace for a wrong XML. Client receives 
HTTP 500
Daemon Thread [https-jsse-nio-8041-exec-18]
org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:262)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getSOAPMessage(WSS4JInInterceptor.java:167)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:234)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:200)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:80)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:67)
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)...


The new codeline gets a HTTP 202.

Can this be the root cause, that the incoming payload is not read before 
returning HTTP 202, hence the input stream is later not available anymore?

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will

[jira] [Created] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2024-12-17 Thread Manuel Shenavai (Jira)

Manuel Shenavai created CXF-9091:


 Summary: Camel 3|CXF: ParsingErrors with OneWay Messages
 Key: CXF-9091
 URL: https://issues.apache.org/jira/browse/CXF-9091
 Project: CXF
  Issue Type: Bug
Reporter: Manuel Shenavai


Hi everyone,

we recently moved from Camel 2 to Camel 3 and we are now observing the 
following problem with CXF. If a OneWay message exceeds a certain length, the 
messages fail with a parser error like:

Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT or 
END_ELEMENT
at 
com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805) 
~[woodstox-core-6.2.7.jar:6.2.7]
at 
org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
 ~[cxf-core-3.5.2.jar:3.5.2]
at 
org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
 ~[cxf-core-3.5.2.jar:3.5.2]
at 
org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
 ~[camel-support-3.17.0.jar:3.17.0]
... 30 common frames omitted

The error will not happen if we reduce the length of the message or if we 
change it from OneWay to ResponseReply. This indicates a problem in the async 
decoupling of the request.

During debugging I found that the HTTP thread is used to handle the request. 
But the actual processing of the message happens in new thread. Maybe the input 
stream is closed after the http thread is finished (HTTP 202) and the spawned 
thread cannot read the full content anymore.

I created the following reproducer based on Spring Boot: 
[https://github.com/mash-sap/cxfOneWayError/tree/main]
CXF: 3.6.5
Camel CXF: 3.17.0
Tomcat: 9.0.83



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2024-12-17 Thread Manuel Shenavai (Jira)



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

Manuel Shenavai updated CXF-9091:
-
Description: 
Hi everyone,

we recently moved from Camel 2 to Camel 3 and we are now observing the 
following problem with CXF. If a OneWay message exceeds a certain length, the 
messages fail with a parser error like:

Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT or 
END_ELEMENT
at 
com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805) 
~[woodstox-core-6.2.7.jar:6.2.7]
at 
org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
 ~[cxf-core-3.5.2.jar:3.5.2]
at 
org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
 ~[cxf-core-3.5.2.jar:3.5.2]
at 
org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
 ~[camel-support-3.17.0.jar:3.17.0]
... 30 common frames omitted

The error will not happen if we reduce the length of the message or if we 
change it from OneWay to ResponseReply. This indicates a problem in the async 
decoupling of the request.

During debugging I found that the HTTP thread is used to handle the request. 
But the actual processing of the message happens in new thread. Maybe the input 
stream is closed after the http thread is finished (HTTP 202) and the spawned 
thread cannot read the full content anymore.

I created the following reproducer based on Spring Boot: 
[https://github.com/mash-sap/cxfOneWayError/tree/main]
CXF: 3.6.5
Camel CXF: 3.17.0
Tomcat: 9.0.83

Mailinglist Post: 
https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x

  was:
Hi everyone,

we recently moved from Camel 2 to Camel 3 and we are now observing the 
following problem with CXF. If a OneWay message exceeds a certain length, the 
messages fail with a parser error like:

Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT or 
END_ELEMENT
at 
com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805) 
~[woodstox-core-6.2.7.jar:6.2.7]
at 
org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
 ~[cxf-core-3.5.2.jar:3.5.2]
at 
org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
 ~[cxf-core-3.5.2.jar:3.5.2]
at 
org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
 ~[camel-support-3.17.0.jar:3.17.0]
... 30 common frames omitted

The error will not happen if we reduce the length of the message or if we 
change it from OneWay to ResponseReply. This indicates a problem in the async 
decoupling of the request.

During debugging I found that the HTTP thread is used to handle the request. 
But the actual processing of the message happens in new thread. Maybe the input 
stream is closed after the http thread is finished (HTTP 202) and the spawned 
thread cannot read the full content anymore.

I created the following reproducer based on Spring Boot: 
[https://github.com/mash-sap/cxfOneWayError/tree/main]
CXF: 3.6.5
Camel CXF: 3.17.0
Tomcat: 9.0.83


> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2024-12-18 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906642#comment-17906642
 ] 

Manuel Shenavai commented on CXF-9091:
--

One noteable observation:
Sending an incomplete payload which is expected to be not parseable, a HTTP 202 
returned in the new codeline. While on the old codeline this same request 
failed already in the HTTP thread, which led to HTTP 500 instead of HTTP 202.

In our old codeline, this is the stacktrace for a wrong XML. Client receives 
HTTP 500
Daemon Thread [https-jsse-nio-8041-exec-18]
org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:262)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getSOAPMessage(WSS4JInInterceptor.java:167)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:234)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:200)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:80)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:67)
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)...


The new codeline gets a HTTP 202.

Can this be the root cause, that the incoming payload is not read before 
returning HTTP 202, hence the input stream is later not available anymore?

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-08 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911014#comment-17911014
 ] 

Manuel Shenavai commented on CXF-9091:
--

Thanks for your replies! We rely on oneway and we will not be able to apply the 
workaround. I hope you can troubleshoot this soon!

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-09 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911372#comment-17911372
 ] 

Manuel Shenavai commented on CXF-9091:
--

Hi [~ffang], just to emphasize my previous comment:
You can see that in the old codeline there was a interceptor 
(PolicyBasedWSS4JInInterceptor) reading the payload before any response code 
was returned. The old codeline would not return HTTP 202 before reading the 
complete payload.
In my test I send a invalid XML to the endpoint. In old codeline, the response 
is 500 while in the new codeline the broken payload is accepted and HTTP 202 is 
returned.

So I think a potential fix would require to read the complete payload before 
returning HTTP 202.

Best regards,
Manuel


Daemon Thread [https-jsse-nio-8041-exec-18]
org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:262)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getSOAPMessage(WSS4JInInterceptor.java:167)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:234)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:200)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:80)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:67)
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)...

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-08 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911185#comment-17911185
 ] 

Manuel Shenavai commented on CXF-9091:
--

Hi [~ffang], 

we got a fork of Camel 2.24.2 and CXF 3.2.11.

Best regards,
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-08 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911185#comment-17911185
 ] 

Manuel Shenavai edited comment on CXF-9091 at 1/8/25 5:46 PM:
--

Hi [~ffang], 

we got a fork of Camel 2.24.2, CXF 3.2.11 and Tomcat 8.5.

Best regards,
Manuel


was (Author: mash-sap):
Hi [~ffang], 

we got a fork of Camel 2.24.2 and CXF 3.2.11.

Best regards,
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9097) Camel 3|CXF|Tomcat: Request has been recycled

2025-01-20 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914694#comment-17914694
 ] 

Manuel Shenavai commented on CXF-9097:
--

https://github.com/apache/cxf/commit/d190dd1abec8ad86b88d6afe539152aa67f7ad43

> Camel 3|CXF|Tomcat: Request has been recycled
> -
>
> Key: CXF-9097
> URL: https://issues.apache.org/jira/browse/CXF-9097
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.6.5, 4.0.6
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.6.6, 4.0.7
>
>
> We see the following error when calling a oneWay endpoint on Tomcat 9:
> java.lang.IllegalStateException: The request object has been recycled and is 
> no longer associated with this facade
>   at 
> org.apache.catalina.connector.RequestFacade.checkFacade(RequestFacade.java:856)
>  ~[tomcat-embed-core-9.0.83.jar:9.0.83]
>   at 
> org.apache.catalina.connector.RequestFacade.getUserPrincipal(RequestFacade.java:610)
>  ~[tomcat-embed-core-9.0.83.jar:9.0.83]
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination$2.getUserPrincipal(AbstractHTTPDestination.java:397)
>  ~[cxf-rt-transports-http-3.6.5.jar:3.6.5]
>   at 
> org.apache.camel.component.cxf.DefaultCxfBinding.populateExchangeFromCxfRequest(DefaultCxfBinding.java:317)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
>   at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.prepareCamelExchange(CxfConsumer.java:297)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
>   at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:235)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
>   at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
>  ~[na:na]
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) 
> ~[na:na]
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:277)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:139)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:413)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>  ~[na:na]
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>  ~[na:na]
>   at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:346)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at java.base/java.lang.Thread.run(Thread.java:840) ~[na:na]
> The problem seems to be related to Tomcat 9 / org.apache.catalina.connector. 
> RECYCLE_FACADES
> https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html
> Camel: 3.17
> CXF: 3.6.5
> Tomcat 9.0.98
> Reproducer:
> https://github.com/mash-sap/cxfOneWayError/blob/recycleError/README.md



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9097) Camel 3|CXF|Tomcat: Request has been recycled

2025-01-20 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914696#comment-17914696
 ] 

Manuel Shenavai commented on CXF-9097:
--

Thanks for fixing this problem [~ffang]!

> Camel 3|CXF|Tomcat: Request has been recycled
> -
>
> Key: CXF-9097
> URL: https://issues.apache.org/jira/browse/CXF-9097
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.6.5, 4.0.6
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.6.6, 4.0.7
>
>
> We see the following error when calling a oneWay endpoint on Tomcat 9:
> java.lang.IllegalStateException: The request object has been recycled and is 
> no longer associated with this facade
>   at 
> org.apache.catalina.connector.RequestFacade.checkFacade(RequestFacade.java:856)
>  ~[tomcat-embed-core-9.0.83.jar:9.0.83]
>   at 
> org.apache.catalina.connector.RequestFacade.getUserPrincipal(RequestFacade.java:610)
>  ~[tomcat-embed-core-9.0.83.jar:9.0.83]
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination$2.getUserPrincipal(AbstractHTTPDestination.java:397)
>  ~[cxf-rt-transports-http-3.6.5.jar:3.6.5]
>   at 
> org.apache.camel.component.cxf.DefaultCxfBinding.populateExchangeFromCxfRequest(DefaultCxfBinding.java:317)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
>   at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.prepareCamelExchange(CxfConsumer.java:297)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
>   at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:235)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
>   at 
> org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
>  ~[na:na]
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) 
> ~[na:na]
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:277)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:139)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:413)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>  ~[na:na]
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>  ~[na:na]
>   at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:346)
>  ~[cxf-core-3.6.5.jar:3.6.5]
>   at java.base/java.lang.Thread.run(Thread.java:840) ~[na:na]
> The problem seems to be related to Tomcat 9 / org.apache.catalina.connector. 
> RECYCLE_FACADES
> https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html
> Camel: 3.17
> CXF: 3.6.5
> Tomcat 9.0.98
> Reproducer:
> https://github.com/mash-sap/cxfOneWayError/blob/recycleError/README.md



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-21 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914945#comment-17914945
 ] 

Manuel Shenavai commented on CXF-9091:
--

Hi [~ffang],
I tried to further understand the problem and created the following project:
https://github.com/mash-sap/cxfOneWayError/tree/parserError

In this project you can remove the SoapOutEndingInterceptor by commenting 
following line:
https://github.com/mash-sap/cxfOneWayError/blob/parserError/src/main/java/de/mash/demo/RemoveInterceptorPreStream.java#L21

If we remove the SoapOutEndingInterceptor from the chain, the parser error is 
not happening. If we keep it in the chain, the parser error is coming up again.

Unfortunately I dont understand why writing to the StreamWriter 
(SoapOutEndingInterceptor) would break the StreamReader 
(CachedCXFPayload/StaxUtils).


The SoapOutEndingInterceptor:
https://github.com/apache/cxf/blob/3.6.x-fixes/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/SoapOutInterceptor.java#L302

Parser Error is happening here:
https://github.com/apache/cxf/blob/3.6.x-fixes/core/src/main/java/org/apache/cxf/staxutils/StaxUtils.java#L718


I share this with you, so maybe this example can help you to troubleshoot this 
problem.

Best regards,
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-10 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911952#comment-17911952
 ] 

Manuel Shenavai commented on CXF-9091:
--

I just noticed that this problem is only happening with ws-addressing. If the 
policy is removed from the endpoint (and the payload is adapted to not send the 
addressing headers), the reported problem is not happening. So it seems to be 
related to wsAddressing.

This is the policy from the wsdl:

http://schemas.xmlsoap.org/ws/2004/09/policy"; 
wsu:Id="BN__binding"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>


http://www.w3.org/2006/05/addressing/wsdl"/>




> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-09 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911600#comment-17911600
 ] 

Manuel Shenavai commented on CXF-9091:
--

Hi [~ffang],
do you mean to say that this is not a bug?
Best regards,
Manuel

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-10 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17912100#comment-17912100
 ] 

Manuel Shenavai commented on CXF-9091:
--

That makes sense, thanks for confirming [~ffang].

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-17 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914015#comment-17914015
 ] 

Manuel Shenavai edited comment on CXF-9091 at 1/17/25 9:09 AM:
---

I found that in Camel 2, this problem will not occur if the WSDL contains the 
following policy (attaching the full wsdl to this ticket). Does anyone know to 
which runtime components this relates?

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>












































was (Author: mash-sap):
I found that in Camel 2, this problem will not occur if the WSDL contains the 
following policy (attaching the full wsdl to this ticket):

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>











































> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.1

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-17 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914015#comment-17914015
 ] 

Manuel Shenavai commented on CXF-9091:
--

I found that in Camel 2, this problem will not occur if the WSDL contains the 
following policy (attaching the full wsdl to this ticket):

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>











































> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-01-17 Thread Manuel Shenavai (Jira)



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

Manuel Shenavai updated CXF-9091:
-
Attachment: GenericRequestReply_wsdl_myendpoint.wsdl

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CXF-9097) Camel 3|CXF|Tomcat: Request has been recycled

2025-01-09 Thread Manuel Shenavai (Jira)

Manuel Shenavai created CXF-9097:


 Summary: Camel 3|CXF|Tomcat: Request has been recycled
 Key: CXF-9097
 URL: https://issues.apache.org/jira/browse/CXF-9097
 Project: CXF
  Issue Type: Bug
Reporter: Manuel Shenavai


We see the following error when calling a oneWay endpoint on Tomcat 9:
java.lang.IllegalStateException: The request object has been recycled and is no 
longer associated with this facade
at 
org.apache.catalina.connector.RequestFacade.checkFacade(RequestFacade.java:856) 
~[tomcat-embed-core-9.0.83.jar:9.0.83]
at 
org.apache.catalina.connector.RequestFacade.getUserPrincipal(RequestFacade.java:610)
 ~[tomcat-embed-core-9.0.83.jar:9.0.83]
at 
org.apache.cxf.transport.http.AbstractHTTPDestination$2.getUserPrincipal(AbstractHTTPDestination.java:397)
 ~[cxf-rt-transports-http-3.6.5.jar:3.6.5]
at 
org.apache.camel.component.cxf.DefaultCxfBinding.populateExchangeFromCxfRequest(DefaultCxfBinding.java:317)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.prepareCamelExchange(CxfConsumer.java:297)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.syncInvoke(CxfConsumer.java:235)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.camel.component.cxf.CxfConsumer$CxfConsumerInvoker.invoke(CxfConsumer.java:162)
 ~[camel-cxf-3.17.0.jar:3.17.0]
at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
 ~[na:na]
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) 
~[na:na]
at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:277)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:139)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:413)
 ~[cxf-core-3.6.5.jar:3.6.5]
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
 ~[na:na]
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 ~[na:na]
at 
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:346)
 ~[cxf-core-3.6.5.jar:3.6.5]
at java.base/java.lang.Thread.run(Thread.java:840) ~[na:na]


The problem seems to be related to Tomcat 9 / org.apache.catalina.connector. 
RECYCLE_FACADES
https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html

Camel: 3.17
CXF: 3.6.5
Tomcat 9.0.98

Reproducer:
https://github.com/mash-sap/cxfOneWayError/blob/recycleError/README.md




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9091) Camel 3|CXF: ParsingErrors with OneWay Messages

2025-02-11 Thread Manuel Shenavai (Jira)



[ 
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926200#comment-17926200
 ] 

Manuel Shenavai commented on CXF-9091:
--

Thanks [~ffang]!

> Camel 3|CXF: ParsingErrors with OneWay Messages
> ---
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
>  Issue Type: Bug
>Reporter: Manuel Shenavai
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.6.6, 4.0.7, 4.1.1
>
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the 
> following problem with CXF. If a OneWay message exceeds a certain length, the 
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT 
> or END_ELEMENT
> at 
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
>  ~[woodstox-core-6.2.7.jar:6.2.7]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
>  ~[cxf-core-3.5.2.jar:3.5.2]
> at 
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.(DelegatingXMLStreamReader.java:40)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
>  ~[camel-cxf-3.17.0.jar:3.17.0]
> at 
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
>  ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we 
> change it from OneWay to ResponseReply. This indicates a problem in the async 
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request. 
> But the actual processing of the message happens in new thread. Maybe the 
> input stream is closed after the http thread is finished (HTTP 202) and the 
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot: 
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post: 
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Reopened] (CXF-9123) Payload written to logs

2025-03-31 Thread Manuel Shenavai (Jira)



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

Manuel Shenavai reopened CXF-9123:
--

Thanks [~reta]. I can see that the now only the hash is printed:
https://github.com/apache/cxf/blob/4fc8b120d7c7363c70324ff8c790494655ad3fa4/core/src/main/java/org/apache/cxf/io/DelayedCachedOutputStreamCleaner.java#L132

This is fixing the problem mentioned in DelayedCachedOutputStreamCleaner. But I 
still see the toString() of CachedOutputStream is writing its content. If 
somewhere else toString() is invoked on this, a simliar problem could easily 
come up. Should this toString() be changed?

> Payload written to logs
> ---
>
> Key: CXF-9123
> URL: https://issues.apache.org/jira/browse/CXF-9123
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Reporter: Manuel Shenavai
>Priority: Major
>
> When tmp files are cleaned up by DelayedCachedOutputStreamCleaner, the 
> content of the tmp file is written into the logs:
> https://github.com/apache/cxf/blob/4fc8b120d7c7363c70324ff8c790494655ad3fa4/core/src/main/java/org/apache/cxf/io/DelayedCachedOutputStreamCleaner.java#L132
> https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/io/CachedOutputStream.java#L430
> Writing the payloads into the logs is a security problem.
> Example log:
> 2025-03-24T18:34:21.17+0530 [...] "Unclosed (leaked?) stream detected: 
> [org.apache.cxf.io.CachedOutputStream Content:

[jira] [Created] (CXF-9123) Payload written to logs

2025-03-31 Thread Manuel Shenavai (Jira)

Manuel Shenavai created CXF-9123:


 Summary: Payload written to logs
 Key: CXF-9123
 URL: https://issues.apache.org/jira/browse/CXF-9123
 Project: CXF
  Issue Type: Bug
  Components: Core
Reporter: Manuel Shenavai


When tmp files are cleaned up by DelayedCachedOutputStreamCleaner, the content 
of the tmp file is written into the logs:
https://github.com/apache/cxf/blob/4fc8b120d7c7363c70324ff8c790494655ad3fa4/core/src/main/java/org/apache/cxf/io/DelayedCachedOutputStreamCleaner.java#L132
https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/io/CachedOutputStream.java#L430

Writing the payloads into the logs is a security problem.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CXF-9123) Payload written to logs

2025-04-04 Thread Manuel Shenavai (Jira)



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

Manuel Shenavai updated CXF-9123:
-
Description: 
When tmp files are cleaned up by DelayedCachedOutputStreamCleaner, the content 
of the tmp file is written into the logs:
https://github.com/apache/cxf/blob/4fc8b120d7c7363c70324ff8c790494655ad3fa4/core/src/main/java/org/apache/cxf/io/DelayedCachedOutputStreamCleaner.java#L132
https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/io/CachedOutputStream.java#L430

Writing the payloads into the logs is a security problem.

Example log:
2025-03-24T18:34:21.17+0530 [...] "Unclosed (leaked?) stream detected: 
[org.apache.cxf.io.CachedOutputStream Content: https://github.com/apache/cxf/blob/4fc8b120d7c7363c70324ff8c790494655ad3fa4/core/src/main/java/org/apache/cxf/io/DelayedCachedOutputStreamCleaner.java#L132
https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/io/CachedOutputStream.java#L430

Writing the payloads into the logs is a security problem.


> Payload written to logs
> ---
>
> Key: CXF-9123
> URL: https://issues.apache.org/jira/browse/CXF-9123
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Reporter: Manuel Shenavai
>Priority: Major
>
> When tmp files are cleaned up by DelayedCachedOutputStreamCleaner, the 
> content of the tmp file is written into the logs:
> https://github.com/apache/cxf/blob/4fc8b120d7c7363c70324ff8c790494655ad3fa4/core/src/main/java/org/apache/cxf/io/DelayedCachedOutputStreamCleaner.java#L132
> https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/io/CachedOutputStream.java#L430
> Writing the payloads into the logs is a security problem.
> Example log:
> 2025-03-24T18:34:21.17+0530 [...] "Unclosed (leaked?) stream detected: 
> [org.apache.cxf.io.CachedOutputStream Content:

49 matches

Mail list logo