[
https://issues.apache.org/jira/browse/CAMEL-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-4452.
---------------------------------
Resolution: Fixed
Applied the patch into trunk and 2.8.x branch.
> 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
> Assignee: Willem Jiang
> Fix For: 2.8.2, 2.9.0
>
> Attachments: test.tar.gz
>
>
> 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
