Re: svn commit: r1170077 - in /camel/trunk: components/camel-jpa/pom.xml components/camel-jpa/src/main/java/org/apache/camel/component/jpa/JpaConsumer.java parent/pom.xml platforms/karaf/features/src/
It works on mac osx
[INFO]
[INFO] --- maven-bundle-plugin:2.3.5:install (default-install) @ camel-jpa ---
[INFO] Installing
org/apache/camel/camel-jpa/2.9-SNAPSHOT/camel-jpa-2.9-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO]
[INFO] BUILD SUCCESS
[INFO]
But fails on WinXP as well
Tests run: 42, Failures: 0, Errors: 4, Skipped: 0
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1:04.812s
[INFO] Finished at: Thu Sep 15 09:14:59 CEST 2011
[INFO] Final Memory: 10M/26M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.8:test (default-test)
on project camel-j
pa: There are test failures.
[ERROR]
[ERROR] Please refer to
E:\workspace\camel\components\camel-jpa\target\surefire-reports for
the individual test results.
I assume its the maven enhance plugin that has some issues. Could be
something related to tools.jar as its default on mac osx, but the
other OS's its not.
On Thu, Sep 15, 2011 at 3:34 AM, Hadrian Zbarcea wrote:
> I believe this patch broke 4 tests in camel-jpa. See test results below:
>
> Tests in error:
>
> testSendTraceMessage(org.apache.camel.processor.interceptor.JpaTraceEventMessageTest):
> Could not open JPA EntityManager for transaction; nested exception is
>
> org.apache.openjpa.persistence.ArgumentException: This configuration
> disallows runtime optimization, but the following listed types were not
> enhanced at build time or at class load time with a javaagent: "
>
> testFileConsumerJpaIdempotent(org.apache.camel.processor.jpa.FileConsumerJpaIdempotentTest):
> Could not open JPA EntityManager for transaction; nested exception is
>
> org.apache.openjpa.persistence.ArgumentException: This configuration
> disallows runtime optimization, but the following listed types were not
> enhanced at build time or at class load time with a javaagent: "
>
> testDuplicateMessagesAreFilteredOut(org.apache.camel.processor.jpa.JpaIdempotentConsumerTest):
> Could not open JPA EntityManager for transaction; nested exception is
>
> org.apache.openjpa.persistence.ArgumentException: This configuration
> disallows runtime optimization, but the following listed types were not
> enhanced at build time or at class load time with a javaagent: "
>
> testFailedExchangesNotAdded(org.apache.camel.processor.jpa.JpaIdempotentConsumerTest):
> Could not open JPA EntityManager for transaction; nested exception is
>
> org.apache.openjpa.persistence.ArgumentException: This configuration
> disallows runtime optimization, but the following listed types were not
> enhanced at build time or at class load time with a javaagent: "
>
> Tests run: 42, Failures: 0, Errors: 4, Skipped: 0
>
>
>
> Hadrian
>
> On 09/13/2011 04:18 AM, davscl...@apache.org wrote:
>>
>> Author: davsclaus
>> Date: Tue Sep 13 08:18:08 2011
>> New Revision: 1170077
>>
>> URL: http://svn.apache.org/viewvc?rev=1170077&view=rev
>> Log:
>> CAMEL-3742: Upgraded camel-jpa to JPA2 spec. Thanks to Ioannis for the
>> patch.
>>
>> Modified:
>> camel/trunk/components/camel-jpa/pom.xml
>>
>> camel/trunk/components/camel-jpa/src/main/java/org/apache/camel/component/jpa/JpaConsumer.java
>> camel/trunk/parent/pom.xml
>> camel/trunk/platforms/karaf/features/src/main/resources/features.xml
>> camel/trunk/pom.xml
>>
>> Modified: camel/trunk/components/camel-jpa/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/camel/trunk/components/camel-jpa/pom.xml?rev=1170077&r1=1170076&r2=1170077&view=diff
>>
>> ==
>> --- camel/trunk/components/camel-jpa/pom.xml (original)
>> +++ camel/trunk/components/camel-jpa/pom.xml Tue Sep 13 08:18:08 2011
>> @@ -66,8 +66,8 @@
>> spring-orm
>>
>>
>> -org.apache.servicemix.specs
>>
>> -org.apache.servicemix.specs.java-persistence-api-1.1.1
>> +org.apache.geronimo.specs
>> +geronimo-jpa_2.0_spec
>> provided
>>
>>
>> @@ -103,50 +103,28 @@
>>
>>
>>
>> -
>> -
>> -
>> -
>> -
>> -org.apache.maven.plugins
>> -maven-antrun-plugin
>> -
>> -
>> -process-test-classes
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -> classname="org.apache.openjpa.ant.PCEnhancerTask">
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -> />
>> -
>> -> propertiesFile="${basedir}/src/test/resources/META-INF/persistence.xml" />
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -run
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> +
>> +
>> +
>> +
>> +org.codehaus.mojo
>> +openjpa-maven-plugin
>> +1.2
>> +
>> +org/apache/camel/examples/*.class
>> +true
>> +true
>> +
>> +
>> +
>> +enhancer
>> +process-test-classes
>> +
>> +test-enhance
>> +
>> +
>> +
>> +
>> +
>> +
>>
>>
>
[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
Re: svn commit: r1170077 - in /camel/trunk: components/camel-jpa/pom.xml components/camel-jpa/src/main/java/org/apache/camel/component/jpa/JpaConsumer.java parent/pom.xml platforms/karaf/features/src/
Okay I got it fixed now. It passes on my win xp box now [INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ camel-jpa --- [INFO] Installing E:\workspace\camel\components\camel-jpa\target\camel-jpa-2.9-SNAPSHOT.jar to e:\maven-repo\org\apache\ camel\camel-jpa\2.9-SNAPSHOT\camel-jpa-2.9-SNAPSHOT.jar [INFO] Installing E:\workspace\camel\components\camel-jpa\pom.xml to e:\maven-repo\org\apache\camel\camel-jpa\2.9-SNAPSH OT\camel-jpa-2.9-SNAPSHOT.pom [INFO] [INFO] --- maven-bundle-plugin:2.3.5:install (default-install) @ camel-jpa --- [INFO] Installing org/apache/camel/camel-jpa/2.9-SNAPSHOT/camel-jpa-2.9-SNAPSHOT.jar [INFO] Writing OBR metadata [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 42.047s [INFO] Finished at: Thu Sep 15 10:44:17 CEST 2011 [INFO] Final Memory: 11M/30M [INFO] -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
[jira] [Created] (CAMEL-4453) Avoid reference from api to builder (ErrorHandlerBuilder) and clean up model in regard to error handler
Avoid reference from api to builder (ErrorHandlerBuilder) and clean up model in regard to error handler --- Key: CAMEL-4453 URL: https://issues.apache.org/jira/browse/CAMEL-4453 Project: Camel Issue Type: Improvement Affects Versions: 2.8.0 Reporter: Christian Schneider Fix For: 2.9.0 Currently we have some lees than optimal designs in camel: The api and spi reference ErrorHandlerbuilder which is a builder level interface. As the builder needs access to almost anything this creates a big cycle over all of camel. We also use the ErrorHandlerBuilder in many places where no build is necessary. In these cases rather a factory is needed. The last thing is that we allow to change the ErrorHandlerBuilder in ProcessDefintion. So it can be set everywhere though it really should only be set on the start of a RouteDefinition. So I propose to change several things: - Create an interface ErrorHandlerFactory that only has the create method and use it instead of ErrorHandlerBuilder where no builder is needed - Remove ErrorHandlerBuilder in ProcessDefintion and only have it in RouteDefintion The first part should be made compatible using deprecation so people will not be affected. The second part is incompatible but I doubt many people use the errorhandler outside the start of a Route. So I think we need to compatiblity measures. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1171054 - in /camel/trunk: camel-core/src/main/java/org/apache/camel/ camel-core/src/main/java/org/apache/camel/builder/ camel-core/src/main/java/org/apache/camel/impl/ camel-core/src
Sorry about that I was pretty sure I did a full mvn -Pfastinstall clean install Will take care of it. Christian Am 15.09.2011 13:30, schrieb Claus Ibsen: Hi Christian Could you be a bit more careful when you do this bigger refactorings. We have another compiler error on trunk. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project camel-spring: Compilation failure: Compilation failure: [ERROR] /Users/davsclaus/workspace/camel/components/camel-spring/src/main/java/org/apache/camel/spring/spi/SpringTransactionPolicy.java:[86,38] cannot find symbol [ERROR] symbol : method supportTransacted() [ERROR] location: interface org.apache.camel.ErrorHandlerFactory A good idea is to run a mvn clean install -Dtest=false from the project root. On Thu, Sep 15, 2011 at 1:05 PM, wrote: Author: cschneider Date: Thu Sep 15 11:05:03 2011 New Revision: 1171054 URL: http://svn.apache.org/viewvc?rev=1171054&view=rev Log: CAMEL-4453 Use ErrorHandlerFactory instead of Builder. Remove error handler from ProcessorDefinition and add it in RouteDefinition Added: camel/trunk/camel-core/src/main/java/org/apache/camel/ErrorHandlerFactory.java Modified: camel/trunk/camel-core/src/main/java/org/apache/camel/CamelContext.java camel/trunk/camel-core/src/main/java/org/apache/camel/builder/ErrorHandlerBuilder.java camel/trunk/camel-core/src/main/java/org/apache/camel/builder/ErrorHandlerBuilderRef.java camel/trunk/camel-core/src/main/java/org/apache/camel/impl/DefaultCamelContext.java camel/trunk/camel-core/src/main/java/org/apache/camel/impl/DefaultRouteContext.java camel/trunk/camel-core/src/main/java/org/apache/camel/management/DefaultManagementLifecycleStrategy.java camel/trunk/camel-core/src/main/java/org/apache/camel/management/DefaultManagementNamingStrategy.java camel/trunk/camel-core/src/main/java/org/apache/camel/management/DefaultManagementObjectStrategy.java camel/trunk/camel-core/src/main/java/org/apache/camel/management/mbean/ManagedErrorHandler.java camel/trunk/camel-core/src/main/java/org/apache/camel/model/ModelCamelContext.java camel/trunk/camel-core/src/main/java/org/apache/camel/model/OnExceptionDefinition.java camel/trunk/camel-core/src/main/java/org/apache/camel/model/ProcessorDefinition.java camel/trunk/camel-core/src/main/java/org/apache/camel/model/RouteDefinition.java camel/trunk/camel-core/src/main/java/org/apache/camel/model/RouteDefinitionHelper.java camel/trunk/camel-core/src/main/java/org/apache/camel/model/RoutesDefinition.java camel/trunk/camel-core/src/main/java/org/apache/camel/processor/MulticastProcessor.java camel/trunk/camel-core/src/main/java/org/apache/camel/spi/LifecycleStrategy.java camel/trunk/camel-core/src/main/java/org/apache/camel/spi/ManagementNamingStrategy.java camel/trunk/camel-core/src/main/java/org/apache/camel/spi/ManagementObjectStrategy.java camel/trunk/camel-core/src/main/java/org/apache/camel/spi/RouteContext.java camel/trunk/camel-core/src/test/java/org/apache/camel/impl/DummyLifecycleStrategy.java camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelUseOriginalInBodyTest.java camel/trunk/components/camel-core-osgi/src/main/java/org/apache/camel/core/osgi/OsgiServiceRegistry.java camel/trunk/components/camel-guice/src/main/java/org/apache/camel/guice/GuiceCamelContext.java camel/trunk/components/camel-spring/src/main/java/org/apache/camel/spring/spi/SpringTransactionPolicy.java Modified: camel/trunk/camel-core/src/main/java/org/apache/camel/CamelContext.java URL: http://svn.apache.org/viewvc/camel/trunk/camel-core/src/main/java/org/apache/camel/CamelContext.java?rev=1171054&r1=1171053&r2=1171054&view=diff == --- camel/trunk/camel-core/src/main/java/org/apache/camel/CamelContext.java (original) +++ camel/trunk/camel-core/src/main/java/org/apache/camel/CamelContext.java Thu Sep 15 11:05:03 2011 @@ -699,6 +699,7 @@ public interface CamelContext extends Su /** * Gets the default error handler builder which is inherited by the routes + * @deprecated The return type will be switched to ErrorHandlerFactory in Camel 3.0 * * @return the builder */ @@ -710,8 +711,7 @@ public interface CamelContext extends Su * * @param errorHandlerBuilder the builder */ -@Deprecated -void setErrorHandlerBuilder(ErrorHandlerBuilder errorHandlerBuilder); +void setErrorHandlerBuilder(ErrorHandlerFactory errorHandlerBuilder); /** * Sets the data formats that can be referenced in the routes. Added: camel/trunk/camel-core/src/main/java/org/apache/camel/ErrorHandlerFactory.java URL: http://svn.apache.org/viewvc/camel/trunk/camel-core/src/main/java/org/apache/camel/ErrorHandlerFactory.java?rev=1171054&view=auto
[jira] [Updated] (CAMEL-4454) Support for Cluster Singleton routes
[ https://issues.apache.org/jira/browse/CAMEL-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Carvalho updated CAMEL-4454: - Description: We came up with this problem in our company. I'll try to give a scenario to show the possible need for this feature: == The problem = We have an application bundle in a ear that contains a camel context and some routes. Due the need of HA of the application, this EAR is replicated over several nodes. By doing this, our camel context also get replicated. For most of our usage it's ok to have competing consumers/producers. But we have one specific case where this is a problem. In one end is our cluster with several instances, and we rely heavily on JMS. One specific Queue we use durable subscription to achieve a single consumer on the cluster, while at the same time, in case of failure another node start consuming messages. On the other side, there's an app that uses Hazelcast as a broker for messaging. We then created a route to consume some messages from the hazelcast cache to our Queue on the cluster. Now, if we deploy this route as part of our distribute app, we end with several instances and messages gets duplicated at the destination on the cluster. We need only one active route on the cluster. One could achieve this by deploying the routes to only one app instance, but it would lead to problems when that instance crashes. So we fixed this by putting the ear on JBoss deployha-singleton, which offers us the ability to have only one single active instance at the time. That was ok for us, but we are relying on specific appserver infrastructure for that. == Proposal === If camel somehow used jgroups for instance to comunicate with other instances, it could use the mechanism that jgroups has to elect a master-view. Every master-view context would then deploy it's singleton routes. All other instances would go on passive mode, and have a MessageListener for cluster messages. In case a view has changed because a node dies, the context would then check if it is the new master view, and in positive deploy the singleton routes. It could be a nice addition to camel on a cluster. Maybe even add the jgroups support for more features on the core when requesting cluster based coordination. I'm currently trying this not at camel level, but we have CDI extension bootstraping camel (not using camel-pe for some other reasons). And our extension will then perform this uniqueness in cluster using jgroups to manage the master node, and invoking context.addRoutes(). We separate the external routes by using CDI qualifiers on the RoutesBuilder. was: We came up with this problem in our company. I'll try to give a scenario to show the possible need for this feature: === The problem We have an application bundle in a ear that contains a camel context and some routes. Due the need of HA of the application, this EAR is replicated over several nodes. By doing this, our camel context also get replicated. For most of our usage it's ok to have competing consumers/producers. But we have one specific case where this is a problem. In one end is our cluster with several instances, and we rely heavily on JMS. One specific Queue we use durable subscription to achieve a single consumer on the cluster, while at the same time, in case of failure another node start consuming messages. On the other side, there's an app that uses Hazelcast as a broker for messaging. We then created a route to consume some messages from the hazelcast cache to our Queue on the cluster. Now, if we deploy this route as part of our distribute app, we end with several instances and messages gets duplicated at the destination on the cluster. We need only one active route on the cluster. One could achieve this by deploying the routes to only one app instance, but it would lead to problems when that instance crashes. So we fixed this by putting the ear on JBoss deployha-singleton, which offers us the ability to have only one single active instance at the time. That was ok for us, but we are relying on specific appserver infrastructure for that. === Proposal If camel somehow used jgroups for instance to comunicate with other instances, it could use the mechanism that jgroups has to elect a master-view. Every master-view context would then deploy it's singleton routes. All other instances would go on passive mode, and have a MessageListener
[jira] [Created] (CAMEL-4454) Support for Cluster Singleton routes
Support for Cluster Singleton routes Key: CAMEL-4454 URL: https://issues.apache.org/jira/browse/CAMEL-4454 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.8.0 Reporter: Vinicius Carvalho Priority: Minor We came up with this problem in our company. I'll try to give a scenario to show the possible need for this feature: === The problem We have an application bundle in a ear that contains a camel context and some routes. Due the need of HA of the application, this EAR is replicated over several nodes. By doing this, our camel context also get replicated. For most of our usage it's ok to have competing consumers/producers. But we have one specific case where this is a problem. In one end is our cluster with several instances, and we rely heavily on JMS. One specific Queue we use durable subscription to achieve a single consumer on the cluster, while at the same time, in case of failure another node start consuming messages. On the other side, there's an app that uses Hazelcast as a broker for messaging. We then created a route to consume some messages from the hazelcast cache to our Queue on the cluster. Now, if we deploy this route as part of our distribute app, we end with several instances and messages gets duplicated at the destination on the cluster. We need only one active route on the cluster. One could achieve this by deploying the routes to only one app instance, but it would lead to problems when that instance crashes. So we fixed this by putting the ear on JBoss deployha-singleton, which offers us the ability to have only one single active instance at the time. That was ok for us, but we are relying on specific appserver infrastructure for that. === Proposal If camel somehow used jgroups for instance to comunicate with other instances, it could use the mechanism that jgroups has to elect a master-view. Every master-view context would then deploy it's singleton routes. All other instances would go on passive mode, and have a MessageListener for cluster messages. In case a view has changed because a node dies, the context would then check if it is the new master view, and in positive deploy the singleton routes. It could be a nice addition to camel on a cluster. Maybe even add the jgroups support for more features on the core when requesting cluster based coordination. I'm currently trying this not at camel level, but we have CDI extension bootstraping camel (not using camel-pe for some other reasons). And our extension will then perform this uniqueness in cluster using jgroups to manage the master node, and invoking context.addRoutes(). We separate the external routes by using CDI qualifiers on the RoutesBuilder. -- 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
[
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] [Commented] (CAMEL-4452) CXFConsumer may extract the request message as the response message and this can lead to problems
[
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] [Resolved] (CAMEL-4453) Avoid reference from api to builder (ErrorHandlerBuilder) and clean up model in regard to error handler
[ https://issues.apache.org/jira/browse/CAMEL-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CAMEL-4453. Resolution: Fixed > Avoid reference from api to builder (ErrorHandlerBuilder) and clean up model > in regard to error handler > --- > > Key: CAMEL-4453 > URL: https://issues.apache.org/jira/browse/CAMEL-4453 > Project: Camel > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: Christian Schneider > Fix For: 2.9.0 > > > Currently we have some lees than optimal designs in camel: > The api and spi reference ErrorHandlerbuilder which is a builder level > interface. As the builder needs access to almost anything this creates a big > cycle over all of camel. > We also use the ErrorHandlerBuilder in many places where no build is > necessary. In these cases rather a factory is needed. > The last thing is that we allow to change the ErrorHandlerBuilder in > ProcessDefintion. So it can be set everywhere though it really should only be > set on the start of a RouteDefinition. > So I propose to change several things: > - Create an interface ErrorHandlerFactory that only has the create method and > use it instead of ErrorHandlerBuilder where no builder is needed > - Remove ErrorHandlerBuilder in ProcessDefintion and only have it in > RouteDefintion > The first part should be made compatible using deprecation so people will not > be affected. > The second part is incompatible but I doubt many people use the errorhandler > outside the start of a Route. So I think we need to compatiblity measures. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4411) DefaultPackageScanClassResolver should skip the bundleresource url when it try to find the classes
[ https://issues.apache.org/jira/browse/CAMEL-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-4411. - Resolution: Fixed Fix Version/s: 2.8.2 Applied patch into trunk and camel-2.8.x branch. > DefaultPackageScanClassResolver should skip the bundleresource url when it > try to find the classes > -- > > Key: CAMEL-4411 > URL: https://issues.apache.org/jira/browse/CAMEL-4411 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Willem Jiang >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.8.2, 2.9.0 > > > As the bundleresource url is used in eclipse which is not a generally used, > and DefaultPackageScanClassResolver just look up the class by using the file > directory lookup, so we should skip the bundleresource url look up in the > DefaultPackageScanClassResolver. -- 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
[
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
[jira] [Updated] (CAMEL-4449) NullPointerException when unmarshalling using serialization data format
[
https://issues.apache.org/jira/browse/CAMEL-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-4449:
---
Fix Version/s: 2.9.0
> NullPointerException when unmarshalling using serialization data format
> ---
>
> Key: CAMEL-4449
> URL: https://issues.apache.org/jira/browse/CAMEL-4449
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.8.0
> Environment: MacOS X 10.6.8
> Java 1.6.0_26
> Apache Camel 2.8.0
> Consuming from remote Kestrel queue (XStream marshalling/unmarshalling works
> just fine)
>Reporter: Vadim TSes'ko
> Fix For: 2.9.0
>
>
> Spring configuration:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Exception:
> {code:java}
> run:
> [java] log4j:WARN No appenders could be found for logger
> (org.springframework.context.support.ClassPathXmlApplicationContext).
> [java] log4j:WARN Please initialize the log4j system properly.
> [java] log4j:WARN See
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
> [java] 13:28:07.587 [main] INFO o.a.c.s.h.CamelNamespaceHandler - OSGi
> environment not detected.
> [java] 13:28:09.028 [main] INFO o.a.camel.spring.SpringCamelContext -
> Apache Camel 2.8.0 (CamelContext: camel) is starting
> [java] 13:28:09.028 [main] INFO o.a.camel.spring.SpringCamelContext -
> JMX enabled. Using ManagedManagementStrategy.
> [java] 13:28:09.415 [main] INFO o.a.c.i.c.AnnotationTypeConverterLoader
> - Found 3 packages with 14 @Converter classes to load
> [java] 13:28:09.489 [main] INFO o.a.c.i.c.DefaultTypeConverter - Loaded
> 153 core type converters (total 153 type converters)
> [java] 13:28:09.528 [main] INFO o.a.c.i.c.DefaultTypeConverter - Loaded
> additional 0 type converters (total 153 type converters) in 0.003 seconds
> [java] 13:28:09.730 [main] INFO o.a.c.c.kestrel.KestrelComponent -
> Creating endpoint for queue "feeds" on etl01f, parameters={}
> [java] 13:28:09.967 [main] INFO o.a.c.c.kestrel.KestrelComponent -
> Creating MemcachedClient for etl01f/feeds
> [java] 2011-09-14 13:28:10.073 INFO
> net.spy.memcached.MemcachedConnection: Added {QA
> sa=etl01f/95.108.229.218:22133, #Rops=0, #Wops=0, #iq=0, topRop=null,
> topWop=null, toWrite=0, interested=0} to connect queue
> [java] 2011-09-14 13:28:10.084 INFO
> net.spy.memcached.MemcachedConnection: Connection state changed for
> sun.nio.ch.SelectionKeyImpl@711b50a1
> [java] 13:28:10.293 [main] INFO o.a.c.c.kestrel.KestrelConsumer -
> Starting consumer for kestrel://etl01f/feeds
> [java] 13:28:10.302 [main] INFO o.a.camel.spring.SpringCamelContext -
> Route: route1 started and consuming from: Endpoint[kestrel://etl01f/feeds]
> [java] 13:28:10.318 [main] INFO o.a.camel.spring.SpringCamelContext -
> Total 1 routes, of which 1 is started.
> [java] 13:28:10.318 [main] INFO o.a.camel.spring.SpringCamelContext -
> Apache Camel 2.8.0 (CamelContext: camel) started in 1.291 seconds
> [java] 13:28:12.858 [Camel (camel) thread #0 -
> Poller-kestrel://etl01f/feeds] ERROR o.a.c.processor.DefaultErrorHandler -
> Failed delivery for exchangeId: ID-incubos-osx-local-51787-1315992488896-0-1.
> Exhausted after delivery attempt: 1 caught: java.lang.NullPointerException
> [java] java.lang.NullPointerException: null
> [java] at
> org.apache.camel.impl.SerializationDataFormat.unmarshal(SerializationDataFormat.java:57)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:56)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:69)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)
> [c
[jira] [Commented] (CAMEL-4449) NullPointerException when unmarshalling using serialization data format
[
https://issues.apache.org/jira/browse/CAMEL-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105564#comment-13105564
]
Claus Ibsen commented on CAMEL-4449:
We love contributions, so patches is welcome.
> NullPointerException when unmarshalling using serialization data format
> ---
>
> Key: CAMEL-4449
> URL: https://issues.apache.org/jira/browse/CAMEL-4449
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.8.0
> Environment: MacOS X 10.6.8
> Java 1.6.0_26
> Apache Camel 2.8.0
> Consuming from remote Kestrel queue (XStream marshalling/unmarshalling works
> just fine)
>Reporter: Vadim TSes'ko
> Fix For: 2.9.0
>
>
> Spring configuration:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Exception:
> {code:java}
> run:
> [java] log4j:WARN No appenders could be found for logger
> (org.springframework.context.support.ClassPathXmlApplicationContext).
> [java] log4j:WARN Please initialize the log4j system properly.
> [java] log4j:WARN See
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
> [java] 13:28:07.587 [main] INFO o.a.c.s.h.CamelNamespaceHandler - OSGi
> environment not detected.
> [java] 13:28:09.028 [main] INFO o.a.camel.spring.SpringCamelContext -
> Apache Camel 2.8.0 (CamelContext: camel) is starting
> [java] 13:28:09.028 [main] INFO o.a.camel.spring.SpringCamelContext -
> JMX enabled. Using ManagedManagementStrategy.
> [java] 13:28:09.415 [main] INFO o.a.c.i.c.AnnotationTypeConverterLoader
> - Found 3 packages with 14 @Converter classes to load
> [java] 13:28:09.489 [main] INFO o.a.c.i.c.DefaultTypeConverter - Loaded
> 153 core type converters (total 153 type converters)
> [java] 13:28:09.528 [main] INFO o.a.c.i.c.DefaultTypeConverter - Loaded
> additional 0 type converters (total 153 type converters) in 0.003 seconds
> [java] 13:28:09.730 [main] INFO o.a.c.c.kestrel.KestrelComponent -
> Creating endpoint for queue "feeds" on etl01f, parameters={}
> [java] 13:28:09.967 [main] INFO o.a.c.c.kestrel.KestrelComponent -
> Creating MemcachedClient for etl01f/feeds
> [java] 2011-09-14 13:28:10.073 INFO
> net.spy.memcached.MemcachedConnection: Added {QA
> sa=etl01f/95.108.229.218:22133, #Rops=0, #Wops=0, #iq=0, topRop=null,
> topWop=null, toWrite=0, interested=0} to connect queue
> [java] 2011-09-14 13:28:10.084 INFO
> net.spy.memcached.MemcachedConnection: Connection state changed for
> sun.nio.ch.SelectionKeyImpl@711b50a1
> [java] 13:28:10.293 [main] INFO o.a.c.c.kestrel.KestrelConsumer -
> Starting consumer for kestrel://etl01f/feeds
> [java] 13:28:10.302 [main] INFO o.a.camel.spring.SpringCamelContext -
> Route: route1 started and consuming from: Endpoint[kestrel://etl01f/feeds]
> [java] 13:28:10.318 [main] INFO o.a.camel.spring.SpringCamelContext -
> Total 1 routes, of which 1 is started.
> [java] 13:28:10.318 [main] INFO o.a.camel.spring.SpringCamelContext -
> Apache Camel 2.8.0 (CamelContext: camel) started in 1.291 seconds
> [java] 13:28:12.858 [Camel (camel) thread #0 -
> Poller-kestrel://etl01f/feeds] ERROR o.a.c.processor.DefaultErrorHandler -
> Failed delivery for exchangeId: ID-incubos-osx-local-51787-1315992488896-0-1.
> Exhausted after delivery attempt: 1 caught: java.lang.NullPointerException
> [java] java.lang.NullPointerException: null
> [java] at
> org.apache.camel.impl.SerializationDataFormat.unmarshal(SerializationDataFormat.java:57)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:56)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:69)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.proc
[jira] [Updated] (CAMEL-4449) NullPointerException when unmarshalling using serialization data format
[
https://issues.apache.org/jira/browse/CAMEL-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-4449:
---
Estimated Complexity: Novice (was: Unknown)
> NullPointerException when unmarshalling using serialization data format
> ---
>
> Key: CAMEL-4449
> URL: https://issues.apache.org/jira/browse/CAMEL-4449
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.8.0
> Environment: MacOS X 10.6.8
> Java 1.6.0_26
> Apache Camel 2.8.0
> Consuming from remote Kestrel queue (XStream marshalling/unmarshalling works
> just fine)
>Reporter: Vadim TSes'ko
> Fix For: 2.9.0
>
>
> Spring configuration:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Exception:
> {code:java}
> run:
> [java] log4j:WARN No appenders could be found for logger
> (org.springframework.context.support.ClassPathXmlApplicationContext).
> [java] log4j:WARN Please initialize the log4j system properly.
> [java] log4j:WARN See
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
> [java] 13:28:07.587 [main] INFO o.a.c.s.h.CamelNamespaceHandler - OSGi
> environment not detected.
> [java] 13:28:09.028 [main] INFO o.a.camel.spring.SpringCamelContext -
> Apache Camel 2.8.0 (CamelContext: camel) is starting
> [java] 13:28:09.028 [main] INFO o.a.camel.spring.SpringCamelContext -
> JMX enabled. Using ManagedManagementStrategy.
> [java] 13:28:09.415 [main] INFO o.a.c.i.c.AnnotationTypeConverterLoader
> - Found 3 packages with 14 @Converter classes to load
> [java] 13:28:09.489 [main] INFO o.a.c.i.c.DefaultTypeConverter - Loaded
> 153 core type converters (total 153 type converters)
> [java] 13:28:09.528 [main] INFO o.a.c.i.c.DefaultTypeConverter - Loaded
> additional 0 type converters (total 153 type converters) in 0.003 seconds
> [java] 13:28:09.730 [main] INFO o.a.c.c.kestrel.KestrelComponent -
> Creating endpoint for queue "feeds" on etl01f, parameters={}
> [java] 13:28:09.967 [main] INFO o.a.c.c.kestrel.KestrelComponent -
> Creating MemcachedClient for etl01f/feeds
> [java] 2011-09-14 13:28:10.073 INFO
> net.spy.memcached.MemcachedConnection: Added {QA
> sa=etl01f/95.108.229.218:22133, #Rops=0, #Wops=0, #iq=0, topRop=null,
> topWop=null, toWrite=0, interested=0} to connect queue
> [java] 2011-09-14 13:28:10.084 INFO
> net.spy.memcached.MemcachedConnection: Connection state changed for
> sun.nio.ch.SelectionKeyImpl@711b50a1
> [java] 13:28:10.293 [main] INFO o.a.c.c.kestrel.KestrelConsumer -
> Starting consumer for kestrel://etl01f/feeds
> [java] 13:28:10.302 [main] INFO o.a.camel.spring.SpringCamelContext -
> Route: route1 started and consuming from: Endpoint[kestrel://etl01f/feeds]
> [java] 13:28:10.318 [main] INFO o.a.camel.spring.SpringCamelContext -
> Total 1 routes, of which 1 is started.
> [java] 13:28:10.318 [main] INFO o.a.camel.spring.SpringCamelContext -
> Apache Camel 2.8.0 (CamelContext: camel) started in 1.291 seconds
> [java] 13:28:12.858 [Camel (camel) thread #0 -
> Poller-kestrel://etl01f/feeds] ERROR o.a.c.processor.DefaultErrorHandler -
> Failed delivery for exchangeId: ID-incubos-osx-local-51787-1315992488896-0-1.
> Exhausted after delivery attempt: 1 caught: java.lang.NullPointerException
> [java] java.lang.NullPointerException: null
> [java] at
> org.apache.camel.impl.SerializationDataFormat.unmarshal(SerializationDataFormat.java:57)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:56)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
> ~[camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:69)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:78)
> [camel-core-2.8.0.jar:2.8.0]
> [java] at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsync
[jira] [Commented] (CAMEL-4450) Improve Camel Karaf commands
[ https://issues.apache.org/jira/browse/CAMEL-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105566#comment-13105566 ] Claus Ibsen commented on CAMEL-4450: Thanks Ioannis, do you mind updating the karaf page at http://camel.apache.org/karaf.html Remember to note that these are new commands in Camel 2.9 onwards. > Improve Camel Karaf commands > > > Key: CAMEL-4450 > URL: https://issues.apache.org/jira/browse/CAMEL-4450 > Project: Camel > Issue Type: Improvement > Components: karaf >Affects Versions: 2.8.0 >Reporter: Ioannis Canellos >Assignee: Ioannis Canellos > Attachments: CAMEL-4450-patch.txt > > > The current Karaf commands could use some improvements: > a) list-routes should list the status of the route and the context it belongs > to. > b) list-routes should list stopped routes, currently it lists only started, > suspended etc. > c) start-route should be able to start a stopped route, currently it does not > d) Add a command to suspend routes. > e) Add a command to resume routes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4450) Improve Camel Karaf commands
[ https://issues.apache.org/jira/browse/CAMEL-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105569#comment-13105569 ] Claus Ibsen commented on CAMEL-4450: Committed patch with some checkstyle fixes. > Improve Camel Karaf commands > > > Key: CAMEL-4450 > URL: https://issues.apache.org/jira/browse/CAMEL-4450 > Project: Camel > Issue Type: Improvement > Components: karaf >Affects Versions: 2.8.0 >Reporter: Ioannis Canellos >Assignee: Ioannis Canellos > Attachments: CAMEL-4450-patch.txt > > > The current Karaf commands could use some improvements: > a) list-routes should list the status of the route and the context it belongs > to. > b) list-routes should list stopped routes, currently it lists only started, > suspended etc. > c) start-route should be able to start a stopped route, currently it does not > d) Add a command to suspend routes. > e) Add a command to resume routes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4028) Simple language - Allow to configure prefix and suffix tokens
[
https://issues.apache.org/jira/browse/CAMEL-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-4028:
--
Assignee: Claus Ibsen
> Simple language - Allow to configure prefix and suffix tokens
> -
>
> Key: CAMEL-4028
> URL: https://issues.apache.org/jira/browse/CAMEL-4028
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.7.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.9.0, Future
>
> Attachments:
> CAMEL-4028_Simple_language_-_Allow_to_configure_prefix_and_suffix_tokens_4.patch,
> CAMEL-4028_Simple_language_Spring_Config.patch
>
>
> The simple language uses ${ } tokens by default. However groovy uses those
> for its GString. So we have a clash. Even if you use $simple{ } instead in
> Groovy then you have a clash.
> So we should add support for configuring the tokens so you can remedy the
> GString clash in Groovy.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4028) Simple language - Allow to configure prefix and suffix tokens
[
https://issues.apache.org/jira/browse/CAMEL-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-4028.
Resolution: Fixed
Fix Version/s: (was: Future)
> Simple language - Allow to configure prefix and suffix tokens
> -
>
> Key: CAMEL-4028
> URL: https://issues.apache.org/jira/browse/CAMEL-4028
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.7.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.9.0
>
> Attachments:
> CAMEL-4028_Simple_language_-_Allow_to_configure_prefix_and_suffix_tokens_4.patch,
> CAMEL-4028_Simple_language_Spring_Config.patch
>
>
> The simple language uses ${ } tokens by default. However groovy uses those
> for its GString. So we have a clash. Even if you use $simple{ } instead in
> Groovy then you have a clash.
> So we should add support for configuring the tokens so you can remedy the
> GString clash in Groovy.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4028) Simple language - Allow to configure prefix and suffix tokens
[
https://issues.apache.org/jira/browse/CAMEL-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105584#comment-13105584
]
Claus Ibsen commented on CAMEL-4028:
Thanks for the patch. I have applied it.
> Simple language - Allow to configure prefix and suffix tokens
> -
>
> Key: CAMEL-4028
> URL: https://issues.apache.org/jira/browse/CAMEL-4028
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.7.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.9.0
>
> Attachments:
> CAMEL-4028_Simple_language_-_Allow_to_configure_prefix_and_suffix_tokens_4.patch,
> CAMEL-4028_Simple_language_Spring_Config.patch
>
>
> The simple language uses ${ } tokens by default. However groovy uses those
> for its GString. So we have a clash. Even if you use $simple{ } instead in
> Groovy then you have a clash.
> So we should add support for configuring the tokens so you can remedy the
> GString clash in Groovy.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4366) Expose Exchange Load statistics in Route and Context MBeans
[ https://issues.apache.org/jira/browse/CAMEL-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Ohr updated CAMEL-4366: - Attachment: load-patch-1 > Expose Exchange Load statistics in Route and Context MBeans > --- > > Key: CAMEL-4366 > URL: https://issues.apache.org/jira/browse/CAMEL-4366 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: christian ohr >Priority: Minor > Attachments: load-patch-1 > > > Add load statistics exposing a exponentially moving weighted average for the > number of inflight exchanges in routes and the whole CamelContext. Initially > the window is fixed to 1m, 5m and 15m, just like Linux load figures. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4366) Expose Exchange Load statistics in Route and Context MBeans
[ https://issues.apache.org/jira/browse/CAMEL-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105623#comment-13105623 ] Christian Ohr commented on CAMEL-4366: -- Added first version of exposing exchange loads for context and route over JMX (+ some unit tests) > Expose Exchange Load statistics in Route and Context MBeans > --- > > Key: CAMEL-4366 > URL: https://issues.apache.org/jira/browse/CAMEL-4366 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: christian ohr >Priority: Minor > Attachments: load-patch-1 > > > Add load statistics exposing a exponentially moving weighted average for the > number of inflight exchanges in routes and the whole CamelContext. Initially > the window is fixed to 1m, 5m and 15m, just like Linux load figures. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-4455) Fix URI definition for camel-spring-ws to provide valid URIs
Fix URI definition for camel-spring-ws to provide valid URIs
Key: CAMEL-4455
URL: https://issues.apache.org/jira/browse/CAMEL-4455
Project: Camel
Issue Type: Sub-task
Reporter: Hadrian Zbarcea
URIs consumed as well as produced by spring-ws Endpoints are invalid. Things
that need to be fixed:
* do not use '{' and '}' in the uri, use '(' and ')' instead
* do not rely on #fragements
* make sure SpringWebserviceConfiguration returns the original URI
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4455) Fix URI definition for camel-spring-ws to provide valid URIs
[
https://issues.apache.org/jira/browse/CAMEL-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea reassigned CAMEL-4455:
--
Assignee: Hadrian Zbarcea
> Fix URI definition for camel-spring-ws to provide valid URIs
>
>
> Key: CAMEL-4455
> URL: https://issues.apache.org/jira/browse/CAMEL-4455
> Project: Camel
> Issue Type: Sub-task
>Reporter: Hadrian Zbarcea
>Assignee: Hadrian Zbarcea
> Fix For: 2.9.0
>
>
> URIs consumed as well as produced by spring-ws Endpoints are invalid. Things
> that need to be fixed:
> * do not use '{' and '}' in the uri, use '(' and ')' instead
> * do not rely on #fragements
> * make sure SpringWebserviceConfiguration returns the original URI
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4425) Cleanup usage of improper URIs in Camel
[
https://issues.apache.org/jira/browse/CAMEL-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105686#comment-13105686
]
Hadrian Zbarcea commented on CAMEL-4425:
Added small fix in camel-sql without creating a sub-task.
> Cleanup usage of improper URIs in Camel
> ---
>
> Key: CAMEL-4425
> URL: https://issues.apache.org/jira/browse/CAMEL-4425
> Project: Camel
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Hadrian Zbarcea
>Assignee: Hadrian Zbarcea
> Fix For: 2.9.0
>
>
> There are many components that use improper URIs, which is kinda tolerated by
> Camel and in some instances encouraged by the examples and we provide. Camel
> uses URIs for both identifying and configuring endpoints, which is good.
> However, we should accept valid, properly encoded URIs. See [URI
> spec|http://www.ietf.org/rfc/rfc2396.txt] for more detailed explanation. For
> some components properly encoding URIs is a solution, but URIs may be become
> harder to understand. For instance curly braces are not allowed in URIs, yet
> we support something like "serviceName={namespace}service" in a uri (see
> CAMEL-4405). Properly encoding uris would work (giving us in the example
> above "%7Bnamespace%7Dservice" which is not all that easy to read), but
> better is to come up with alternatives like
> "targetNamespace=namespace&serviceName=service". This problem exists in a few
> other components, not just camel-cxf, so this issue is meant as an umbrella
> for all components.
> As this could have a significant impact on existing applications, I propose a
> solution that will still accept existing syntax for URIs (i.e. no immediate
> impact on existing applications), and come up with configuration alternatives
> per component. When invalid URIs are used, a warning should alert users,
> giving them time to upgrade/migrate their URIs. This fallback mechanism may
> be removed in 3.0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4097) Add option on aggregation to flush on shutdown
[ https://issues.apache.org/jira/browse/CAMEL-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day updated CAMEL-4097: - Attachment: CAMEL-4097.patch Claus, I'm revisiting this. When I worked on a combined patch with CAMEL-4118, you said this..."when stopping, you do not wait for all the exchanges to complete before you continue and shutdown the thread pools etc." I'm not sure I follow. Is there any other place that we do this? If not, any advice on how to do this...thanks > Add option on aggregation to flush on shutdown > -- > > Key: CAMEL-4097 > URL: https://issues.apache.org/jira/browse/CAMEL-4097 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Ben O'Day >Priority: Minor > Fix For: 2.9.0 > > Attachments: CAMEL-4097.patch > > > We may want to add options to stateful EIPs such as aggregator/resequencer > that they should flush on shutdown. People who dont use a persistent store > would loose the in-memory partly aggregated exchanges. > See nabble > http://camel.465427.n5.nabble.com/Aggregator-completeOnShutdown-tp4423774p4423774.html -- 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
[
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] [Resolved] (CAMEL-4452) CXFConsumer may extract the request message as the response message and this can lead to problems
[
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
