You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Aki Yoshida (JIRA)" <ji...@apache.org> on 2011/09/15 10:04:08 UTC
[jira] [Created] (CAMEL-4452) CXFConsumer may extract the request
message as the response message and this can lead to problems
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
[jira] [Commented] (CAMEL-4452) CXFConsumer may extract the request
message as the response message and this can lead to problems
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105368#comment-13105368 ]
Willem Jiang commented on CAMEL-4452:
-------------------------------------
Hi Aki,
I checked the code of NPE, I don't think it relates to the change of CAMEL-4030.
The camelExchange is not same with the cxfExchange, I don't think the oneway invocation can cause the NPE that you mentioned.
I guess there are some thing wrong with the boi.getOutput() checking.
Can you submit the test case into this JIRA to let me have a look?
Willem
> 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
>
>
> 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
[jira] [Commented] (CAMEL-4452) CXFConsumer may extract the request
message as the response message and this can lead to problems
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105886#comment-13105886 ]
Willem Jiang commented on CAMEL-4452:
-------------------------------------
I found the NPE are thrown from other GreeterPayLoad tests, it can be fix by adding an NP checking on the boi.getOutput incase of the boi is oneway operation.
I will commit the fix shortly.
> 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
[jira] [Assigned] (CAMEL-4452) CXFConsumer may extract the request
message as the response message and this can lead to problems
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Willem Jiang reassigned CAMEL-4452:
-----------------------------------
Assignee: Willem Jiang
> 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
>
>
> 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
[jira] [Resolved] (CAMEL-4452) CXFConsumer may extract the request
message as the response message and this can lead to problems
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CAMEL-4452) CXFConsumer may extract the request
message as the response message and this can lead to problems
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106007#comment-13106007 ]
Aki Yoshida commented on CAMEL-4452:
------------------------------------
Hi Willem,
Checking boi.getOutput() != null, as you patched, will avoid the NPE for this oneway case. But I think this solution may lead to some unexpected result in those cases when the getOutput() isn't null but for some reason the response message is not available, no?
I still find it strange to automatically take the request message for the response message.
Or am I missing some point?
regards, aki
> 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
[jira] [Updated] (CAMEL-4452) CXFConsumer may extract the request
message as the response message and this can lead to problems
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aki Yoshida updated CAMEL-4452:
-------------------------------
Attachment: test.tar.gz
Hi Willem,
thanks for looking into this.
Attached is a tar.gz file containing a test case (analogue to the other GreeterTest in camel-cxf) but using the wsdl and no service class.
The logging for the camel cxf component needs to be activated to see the exception stack trace (org.apache.camel.component.cxf.level=INFO
).
The exception comes from the greeter.greetMeOneWay when it tries to extract the response payload out of the request message.
thanks.
regards, aki
> 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