CXFConsumer may extract the request message as the response message and this
can lead to problems
-------------------------------------------------------------------------------------------------
Key: CAMEL-4452
URL: https://issues.apache.org/jira/browse/CAMEL-4452
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.8.0
Reporter: Aki Yoshida
Fix For: 2.8.2, 2.9.0
CAMEL-4030 with Revision 1129070 in trunk changed the way how the response
message is retrieved from the exchange and this is causing some issue.
In particular, the changed code may retrieve the request message as the
response message when the call is oneway (when the condition
camelExchange.getPattern().isOutCapable() is false).
Subsequently, this is leading to an NPE when the output operation is used to
extract the payload body from this request message because there is no output
operations in the oneway case at:
for (MessagePartInfo partInfo : boi.getOutput().getMessageParts()) {
and resulting in:
java.lang.NullPointerException
at
org.apache.camel.component.cxf.DefaultCxfBinding.getResponsePayloadList(DefaultCxfBinding.java:394)
at
org.apache.camel.component.cxf.DefaultCxfBinding.populateCxfResponseFromExchange(DefaultCxfBinding.java:318)
at
org.apache.camel.component.cxf.CxfConsumer$1.setResponseBack(CxfConsumer.java:176)
at
org.apache.camel.component.cxf.CxfConsumer$1.syncInvoke(CxfConsumer.java:126)
at
org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:71)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at
org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:232)
at
org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:130)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:353)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
I see this change was introduced with CAMEL-4030 to support some sort of
wire-tap short-cut:
from("cxf:xxx").inonly("jms:xxx").to("xxx")
I am not sure how this inbound/outbound switching operation relates to this use
case.
But in any case, this new behavior can lead to this problem and I think the
old behavior (skipping the response message part if there is no response)
should be reinstated.
I have a simple test case that can reproduce this problem, but the exception is
thrown in an executor thread and only written to the log and the original test
caller thread doesn't see the exception. So, it's not a useful automatic test
case. Maybe, there is a way. Let me know, how you think.
thanks.
regards, aki
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
