camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Willem Jiang (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CAMEL-4452) CXFConsumer may extract the request message as the response message and this can lead to problems
Date Fri, 16 Sep 2011 06:33:08 GMT

     [ 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

        

Mime
View raw message