Custom AggregationStrategy needs specific headers
Hello, I am using Camel 1.6.1. With the following route: from(timer://timer?period=1000) .setBody(constant(select * from table)) .to(jdbc:db) .splitter(body(List.class), new MyAggregationStrategy()) .to(some default component uri that doesn't forward headers) .end() .to(log:log) The aggregationstrategy needs org.apache.camel.SplitIndex and org.apache.camel.SplitSize but you lose them during the route in the splitter part. I can work around the problem by saving the headers in an exchange property as first step and restore them just before the aggregation, but shouldn't the splitter itself store necessary information in a property? Regards, Erwin -- View this message in context: http://www.nabble.com/Custom-AggregationStrategy-needs-specific-headers-tp23996092p23996092.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Custom AggregationStrategy needs specific headers
On Fri, Jun 12, 2009 at 12:07 PM, ErwinKerwin.kr...@gmail.com wrote: Hello, I am using Camel 1.6.1. With the following route: from(timer://timer?period=1000) .setBody(constant(select * from table)) .to(jdbc:db) .splitter(body(List.class), new MyAggregationStrategy()) .to(some default component uri that doesn't forward headers) .end() .to(log:log) The aggregationstrategy needs org.apache.camel.SplitIndex and org.apache.camel.SplitSize but you lose them during the route in the splitter part. I can work around the problem by saving the headers in an exchange property as first step and restore them just before the aggregation, but shouldn't the splitter itself store necessary information in a property? Hi The aggregation strategy interface is a bit low-level as you work directly on the Exchange object. Doing this you have to be a bit careful whether you set the aggregated response on OUT or IN. If you set it on OUT and you do not copy headers from IN then they are lost. But you are right we could build in failsafe in Camel to safe the headers. But another solution would be to use exchange properties instead of headers, then they are newer lost. I have been wondering if we should migrate Camel 2.0 to use properties for such thinks as splitter indes, aggregator index, and what else Camel decorate an exchange with. It kinda belong there in the first place. Regards, Erwin -- View this message in context: http://www.nabble.com/Custom-AggregationStrategy-needs-specific-headers-tp23996092p23996092.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: How to prevent routes from started twice?
Hi Could you create a JIRA ticket for this. Camel should honor the shouldStartContext when it receives this spring refresh event. On Thu, Jun 11, 2009 at 5:33 PM, akuhtzandreas.ku...@siemens.com wrote: Hi, I've a spring based web application that has 2 applicationContexts (the second has the first as parent). My problem is that the SpringCamelContext listens to the ContextRefreshedEvent and starts the camel context. This works fine if you have only 1 context but if the ContextRefreshedEvent of the second context is received the routes are started a second time. The second start of the camel context is catched correctly (in ServiceSupport) but I think the the startRoutes() in the start()-method of DefaultCamelContext should also prevent to be called twice... My config details: I start the camel context from another thread than that one that creates the ApplicationContext and already I played with the shouldStartContext set to false but this prevents the start the camel context at all. I know that my scenario with the different threads cause this problem but it should be possible to prevent the automatic start with the ContextRefreshedEvent but start the camel context manually. Andreas -- View this message in context: http://www.nabble.com/How-to-prevent-routes-from-started-twice--tp23983653p23983653.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Documenting the Camel DSL
Claus Ibsen schrieb: So I doubt its possible to cover all languages in all DSLs. I suggest to focus solely on Spring and Java DSL. Yes .. Spring and Java DSL are the focues for me too. They are used the most. And we do not absolutely need to have samples for both. Often its possible to translate from one to another. There are some special cases where its not that easy, for instance all related to error handling where the spring DSL is much more different than Java DSL. I sometimes had the problem that I knew how to do it in Java but not in Spring. Though I think these were exactly the cases where spring and Java DSL are different. So my suggestion is to do examples mainly in Spring DSL and in Java DSL only if it is different. By micro management I mean that instead of writing 2-3 sections about what it does and provide a few samples over having to provide a strict format for syntax (with and without optional parameters), tables for each and every option, with defaults. And what not. I think examples only help to a degree. There are many great examples in the Camel Web but I had many cases where I just could not find what I intended to do. In these cases a solid reference docuementation would have helped me greatly. Of course writing a reference is no fun but it is necessary. Though I hope that at some point the documentation can be written once (for example in the java doc) and the web and xsd documentation are generated automatically. I only think that we should not wait till the technology for this is in place as many users of camel are struggling to find a good reference. Often an example speaks 1000 words. Yes. A reference alone would not be enough. Good examples are key to a fast understanding. Often it is a little difficult to find the on the camel web as they are quite scattered. Perhaps there should be two kinds of examples. First the reference based examples. These start with e.g. a function and show several usages. Second are the use case based examples that start with higher level business use case and show how it can be done in camel. I think some of the Cookbook pages go into that direction. And for the EIP I do suggest to improve the existing documentation instead of creating new pages for them. If one of them need a table with options please go ahead and add it. Yes.. absolutely. It would be a shame to not use the fine work that has been done documenting the EIP. Please continue the good intentions and dont stop just because I fear of micro managment and documentation being stalled and out-dated. Either we do it or we dont. I also fear of out dated documentations but at least with the wiki I hope that people from the community help with identifying out dated documentation and even help improving it. Though I do not have too much illusions about it ;-) Greetings Christian
Re: Custom AggregationStrategy needs specific headers
Claus Ibsen-2 wrote: On Fri, Jun 12, 2009 at 12:07 PM, ErwinKerwin.kr...@gmail.com wrote: Hello, I am using Camel 1.6.1. With the following route: from(timer://timer?period=1000) .setBody(constant(select * from table)) .to(jdbc:db) .splitter(body(List.class), new MyAggregationStrategy()) .to(some default component uri that doesn't forward headers) .end() .to(log:log) The aggregationstrategy needs org.apache.camel.SplitIndex and org.apache.camel.SplitSize but you lose them during the route in the splitter part. I can work around the problem by saving the headers in an exchange property as first step and restore them just before the aggregation, but shouldn't the splitter itself store necessary information in a property? Hi The aggregation strategy interface is a bit low-level as you work directly on the Exchange object. Doing this you have to be a bit careful whether you set the aggregated response on OUT or IN. If you set it on OUT and you do not copy headers from IN then they are lost. But you are right we could build in failsafe in Camel to safe the headers. But another solution would be to use exchange properties instead of headers, then they are newer lost. I have been wondering if we should migrate Camel 2.0 to use properties for such thinks as splitter indes, aggregator index, and what else Camel decorate an exchange with. It kinda belong there in the first place. Regards, Erwin -- View this message in context: http://www.nabble.com/Custom-AggregationStrategy-needs-specific-headers-tp23996092p23996092.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus The problem in this case is that I don't really mind to lose my own headers when using a default component, but that the headers set by the splitter are needed in the end for the aggregation. So that means that when you use default components, you have to write some extra code that ensures that the headers are still (or again) there just before the aggregation, otherwise it will just not work. I think it should definitly be addressed in 2.0, but if it is not to hard, also in 1.6.x. If there is a ticket I can see if I can send a patch. Regards, Erwin -- View this message in context: http://www.nabble.com/Custom-AggregationStrategy-needs-specific-headers-tp23996092p23996797.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Documenting the Camel DSL
Hi, I agree on your remarks Christian. It is better to have a single point of entry for syntax about camel DSL language with examples than using google to find out where the info has been defined in the wiki pages of camel. Such a documentation (I will participate to enrich it) is absolutely necessary to simplify job of developers working on a project and avoid that they spend too much time to find info. Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com On Fri, Jun 12, 2009 at 1:00 PM, Christian Schneider ch...@die-schneider.net wrote: Claus Ibsen schrieb: So I doubt its possible to cover all languages in all DSLs. I suggest to focus solely on Spring and Java DSL. Yes .. Spring and Java DSL are the focues for me too. They are used the most. And we do not absolutely need to have samples for both. Often its possible to translate from one to another. There are some special cases where its not that easy, for instance all related to error handling where the spring DSL is much more different than Java DSL. I sometimes had the problem that I knew how to do it in Java but not in Spring. Though I think these were exactly the cases where spring and Java DSL are different. So my suggestion is to do examples mainly in Spring DSL and in Java DSL only if it is different. By micro management I mean that instead of writing 2-3 sections about what it does and provide a few samples over having to provide a strict format for syntax (with and without optional parameters), tables for each and every option, with defaults. And what not. I think examples only help to a degree. There are many great examples in the Camel Web but I had many cases where I just could not find what I intended to do. In these cases a solid reference docuementation would have helped me greatly. Of course writing a reference is no fun but it is necessary. Though I hope that at some point the documentation can be written once (for example in the java doc) and the web and xsd documentation are generated automatically. I only think that we should not wait till the technology for this is in place as many users of camel are struggling to find a good reference. Often an example speaks 1000 words. Yes. A reference alone would not be enough. Good examples are key to a fast understanding. Often it is a little difficult to find the on the camel web as they are quite scattered. Perhaps there should be two kinds of examples. First the reference based examples. These start with e.g. a function and show several usages. Second are the use case based examples that start with higher level business use case and show how it can be done in camel. I think some of the Cookbook pages go into that direction. And for the EIP I do suggest to improve the existing documentation instead of creating new pages for them. If one of them need a table with options please go ahead and add it. Yes.. absolutely. It would be a shame to not use the fine work that has been done documenting the EIP. Please continue the good intentions and dont stop just because I fear of micro managment and documentation being stalled and out-dated. Either we do it or we dont. I also fear of out dated documentations but at least with the wiki I hope that people from the community help with identifying out dated documentation and even help improving it. Though I do not have too much illusions about it ;-) Greetings Christian
Re: How to prevent routes from started twice?
Hi Claus, I does honor but the problem is that you can't start the camel context (from another bean) if shouldStartContext is set to false, and this is the only way to prevent the execution of code that is triggered by refresh event. I'll create a JIRA ticket with a problem description. -- View this message in context: http://www.nabble.com/How-to-prevent-routes-from-started-twice--tp23983653p23997172.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How to prevent routes from started twice?
On Fri, Jun 12, 2009 at 1:30 PM, akuhtzandreas.ku...@siemens.com wrote:
Hi Claus,
I does honor but the problem is that you can't start the camel context (from
another bean) if shouldStartContext is set to false, and this is the only
way to prevent the execution of code that is triggered by refresh event.
I'll create a JIRA ticket with a problem description.
BTW how many times do you see this log line if you enable DEBUG
logging for org.apache.camel?
if (LOG.isDebugEnabled()) {
LOG.debug(Publishing spring-event: + event);
}
--
View this message in context:
http://www.nabble.com/How-to-prevent-routes-from-started-twice--tp23983653p23997172.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: How to prevent routes from started twice?
I see it twice! Once for the root application context (which is correct, because its the context where the camel context is defined in) and a second time for the web application context (which I think is incorrect because it's the child context of the root). I don't know if it would work in all cases if the applicationContext instance of the refresh event would be evaulated and only refresh events for the applicationContext of the camel context is processed ... -- View this message in context: http://www.nabble.com/How-to-prevent-routes-from-started-twice--tp23983653p23997647.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How to prevent routes from started twice?
On Fri, Jun 12, 2009 at 2:08 PM, akuhtzandreas.ku...@siemens.com wrote: I see it twice! Once for the root application context (which is correct, because its the context where the camel context is defined in) and a second time for the web application context (which I think is incorrect because it's the child context of the root). I don't know if it would work in all cases if the applicationContext instance of the refresh event would be evaulated and only refresh events for the applicationContext of the camel context is processed ... Hi Make sure to attach a .zip with a sample project of yours as its something unusual and this is the first time its reported. Are the logs line being logged rapidly right after each other? And do you in fact have 2 x camelContext in spring XML files or only 1 tag? -- View this message in context: http://www.nabble.com/How-to-prevent-routes-from-started-twice--tp23983653p23997647.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Custom AggregationStrategy needs specific headers
Hi I have created a ticket to track this issue https://issues.apache.org/activemq/browse/CAMEL-1702 We will *only* do this migration at Camel 2.0 to keep the old behavior in Camel 1.6.x as this branch is maintenance and for important bug fixes only. Its intended for drop in replacements for production usage and this we cannot change such behavior. Even if it would make life easier. On Fri, Jun 12, 2009 at 1:00 PM, ErwinKerwin.kr...@gmail.com wrote: Claus Ibsen-2 wrote: On Fri, Jun 12, 2009 at 12:07 PM, ErwinKerwin.kr...@gmail.com wrote: Hello, I am using Camel 1.6.1. With the following route: from(timer://timer?period=1000) .setBody(constant(select * from table)) .to(jdbc:db) .splitter(body(List.class), new MyAggregationStrategy()) .to(some default component uri that doesn't forward headers) .end() .to(log:log) The aggregationstrategy needs org.apache.camel.SplitIndex and org.apache.camel.SplitSize but you lose them during the route in the splitter part. I can work around the problem by saving the headers in an exchange property as first step and restore them just before the aggregation, but shouldn't the splitter itself store necessary information in a property? Hi The aggregation strategy interface is a bit low-level as you work directly on the Exchange object. Doing this you have to be a bit careful whether you set the aggregated response on OUT or IN. If you set it on OUT and you do not copy headers from IN then they are lost. But you are right we could build in failsafe in Camel to safe the headers. But another solution would be to use exchange properties instead of headers, then they are newer lost. I have been wondering if we should migrate Camel 2.0 to use properties for such thinks as splitter indes, aggregator index, and what else Camel decorate an exchange with. It kinda belong there in the first place. Regards, Erwin -- View this message in context: http://www.nabble.com/Custom-AggregationStrategy-needs-specific-headers-tp23996092p23996092.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus The problem in this case is that I don't really mind to lose my own headers when using a default component, but that the headers set by the splitter are needed in the end for the aggregation. So that means that when you use default components, you have to write some extra code that ensures that the headers are still (or again) there just before the aggregation, otherwise it will just not work. I think it should definitly be addressed in 2.0, but if it is not to hard, also in 1.6.x. If there is a ticket I can see if I can send a patch. Regards, Erwin -- View this message in context: http://www.nabble.com/Custom-AggregationStrategy-needs-specific-headers-tp23996092p23996797.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Custom AggregationStrategy needs specific headers
Claus Ibsen-2 wrote: Hi I have created a ticket to track this issue https://issues.apache.org/activemq/browse/CAMEL-1702 We will *only* do this migration at Camel 2.0 to keep the old behavior in Camel 1.6.x as this branch is maintenance and for important bug fixes only. Its intended for drop in replacements for production usage and this we cannot change such behavior. Even if it would make life easier. The ticket mentions automatic fallback from header - property. That is not available in 1.6.x as far as I know. That would solve half of the workaround. It is a possibility to use header OR property for aggregation? That would not really break existing implementations because the whole camel namespace is used in the property. The current splitter / aggregation implementation is really fragile without good knowleds of camel 1.6.x Regards, Erwin -- View this message in context: http://www.nabble.com/Custom-AggregationStrategy-needs-specific-headers-tp23996092p24000219.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: No operation found in the CXF client
Hello All,
I solved the issue on Camel 1.6.0. The solution was to add a header called
operationNameSpace:
setHeader
headerName=operationNameSpaceconstanthttp://www.wisconsin.gov/wijis/gateway/PointerUploadService//constant/setHeader
This did the trick. My assumption was that since this message went over a
JMS queue that the header called operationNameSpace was added and took on
the original consuming endpoint namespace of:
operationNameSpace=http://wijiscommons.org/ssaf/drop-off/
This might have been to support Soap over JMS. When I updated this
operation namespace, my service worked. I am concerned that it doesn't work
in 1.6.1. Should I file a JIRA about this?
I also updated the CXF WIKI page:
http://cwiki.apache.org/confluence/display/CAMEL/CXF
I added the sentence: When you are invoking the service endpoint, you can
set the operationName and operationNameSpace headers to explicitly state
which operation you are calling.
Hope this is okay with Camel folks out there.
Cheers,
Yogesh
ychawla wrote:
Hello All,
I am trying to consume a web service as the origin of a camel route and
later on down the line invoke a web service. I have this working by just
consuming an xml message from a folder and invoking a web service, but
when I try to connect the two web services I get an error:
org.apache.camel.RuntimeCamelException: No operation found in the CXF
client, the operation is
{http://wijiscommons.org/ssaf/drop-off/}pointerUpload
at
org.apache.camel.component.cxf.CxfProducer.invokeClient(CxfProducer.java:266)
at
org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:182)
at
org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:155)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:69)
However, the service I am actually trying to call has a different
namespace. Here are the beans:
!-- web service that I call --
cxf:cxfEndpoint id=pointerUploadService
address=https://someURL:17444/xfire/PointerUpload;
serviceClass=somepackage.PointerUploadService
endpointName=puService:PointerUploadService
xmlns:puService=http://www.wisconsin.gov/wijis/gateway/PointerUploadService//
!-- web service that I consume --
cxf:cxfEndpoint id=dropoffSynchronousWebService-endpoint
serviceClass=org.wijiscommons.ssaf.drop_off.DropOffSynchronousService
address=/DropOffSynchronousService
endpointName=s:DropOffSynchronousService
serviceName=s:DropOffSynchronousService
xmlns:s=http://wijiscommons.org/ssaf/drop-off/;
cxf:inInterceptors
ref bean=x509Interceptor/
/cxf:inInterceptors
/cxf:cxfEndpoint
http-conf:conduit name=*.http-conduit
http-conf:tlsClientParameters secureSocketProtocol=SSL
sec:keyManagers keyPassword=changeit
sec:keyStore type=JKS password=changeit
file=something.key/
/sec:keyManagers
sec:trustManagers
sec:keyStore type=JKS password=changeit
file=/somepath/cacerts/
/sec:trustManagers
sec:cipherSuitesFilter
sec:include.*.*/sec:include
/sec:cipherSuitesFilter
/http-conf:tlsClientParameters
/http-conf:conduit
Here are the routes:
route
from uri=cxf:bean:dropoffSynchronousWebService-endpoint /
!-- do a bunch of stuff --
setHeader
headerName=operationNameconstantpointerUpload/constant/setHeader
to uri=cxf:bean:pointerUploadService?dataFormat=POJO /
/route
Note all of the above is in Camel 1.6.0 and CXF 2.1.3
When I upgrade to Camel 1.6.1 and CXF 2.2.2, I get a different error and
am unable to start my server. It looks like it tries to create the same
endpoint twice. Can anyone help me out with what I am doing wrong here?
If I take out either CXF bean, everything works fine, but ideally I would
like to hook these two services up through Camel.
INFO: Creating Service
{http://wijiscommons.org/ssaf/drop-off/}DropOffSynchronousService from
class org.wijiscommons.ssaf.drop_off.DropOffSynchronousService
Jun 11, 2009 1:41:01 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be
/DropOffSynchronousService
Jun 11, 2009 1:41:02 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service
{http://www.wisconsin.gov/wijis/gateway/PointerUploadService/}PointerUploadServiceService
from class
gov.wisconsin.wijis.gateway.pointeruploadservice.PointerUploadService
2009-06-11 13:41:03,141 INFO
Re: How do i use a JMS Consumer in Camel DSL?
Hi
It's a known issue[1], and we fixed it in SMX4 branch.
If you are not comfortable with playing apache SNAPSHOT version, you can
try out the coming up Fuse ESB 4.1.x monthly release version.
[1] http://fusesource.com/issues/browse/ESB-733
Willem
triggershot wrote:
Hey,
i have the following problem. I've defined a JMS - Service Unit with a
Provider and Consumer (like in the Tutorial Camel from
servicemix.apache.org):
##
beans xmlns:jms=http://servicemix.apache.org/jms/1.0;
xmlns:tutorial=urn:org:apache:servicemix:tutorial:camel
xmlns:amq=http://activemq.org/config/1.0;
jms:provider service=tutorial:jms
endpoint=provider
destinationName=tutorial.camel.queue
connectionFactory=#connectionFactory /
jms:consumer service=tutorial:jms
endpoint=consumer
destinationName=tutorial.camel.queue
connectionFactory=#connectionFactory
targetService=tutorial:jms
targetEndpoint=consumer /
amq:connectionFactory id=connectionFactory
brokerURL=tcp://localhost:61616 /
/beans
##
And here is my Camel MyRouteBuilder.java:
##
public class MyRouteBuilder extends RouteBuilder
{
public void configure()
{
from(timer://tutorial?fixedRate=truedelay=3000period=1)
.setBody(constant(messageThis is a test/message))
.convertBodyTo(DOMSource.class)
.to(jbi:endpoint:urn:org:apache:servicemix:tutorial:camel:jms:provider);
from(jbi:endpoint:urn:org:apache:servicemix:tutorial:camel:jms:consumer)
.to(log:mylogger);
}
}
##
The message receives the provider. But my Consumer cannot get the message
from the Queue. I get the following error:
##
13:35:09,500 | WARN | nerContainer-498 | DefaultMessageListenerContainer |
AbstractMessageListenerContainer 646 | Execution of JMS message listener
failed
javax.jms.JMSException: Error sending JBI exchange
at
org.apache.servicemix.jms.endpoints.AbstractConsumerEndpoint.onMessage(AbstractConsumerEndpoint.java:575)
at
org.apache.servicemix.jms.endpoints.JmsConsumerEndpoint$1.onMessage(JmsConsumerEndpoint.java:505)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:518)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:479)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:451)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:323)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:261)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:982)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:974)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:876)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at
org.apache.servicemix.jbi.deployer.artifacts.AssemblyReferencesListener.pending(AssemblyReferencesListener.java:110)
at
org.apache.servicemix.jbi.deployer.artifacts.AssemblyReferencesListener.exchangeSent(AssemblyReferencesListener.java:98)
at
org.apache.servicemix.nmr.core.ChannelImpl.dispatch(ChannelImpl.java:282)
at
org.apache.servicemix.nmr.core.ChannelImpl.sendSync(ChannelImpl.java:141)
at
org.apache.servicemix.nmr.core.ChannelImpl.sendSync(ChannelImpl.java:127)
at
org.apache.servicemix.jbi.runtime.impl.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:187)
at
org.apache.servicemix.common.EndpointDeliveryChannel.sendSync(EndpointDeliveryChannel.java:115)
at
org.apache.servicemix.common.endpoints.SimpleEndpoint.sendSync(SimpleEndpoint.java:74)
at
org.apache.servicemix.jms.endpoints.AbstractConsumerEndpoint.onMessage(AbstractConsumerEndpoint.java:548)
##
What ' s the reason? I only want this:
- write a Message to the JMS provider
- JMS consumer polls the
