Christian, You are still seeing this issue? Once I upgraded I wasn't receiving it any longer but I did have another problem where activemq-camel wasn't importing org.apache.activemq.pool any more. That has now been patched and should be in a nightly here shortly.
Unless when that was fixed they broke the other piece again :) Chris On Thu, Apr 19, 2012 at 12:09 PM, Christian Müller < christian.muel...@gmail.com> wrote: > I mean ActiveMq 5.6-SNAPSHOT... > > Best, > Christian > > On Thu, Apr 19, 2012 at 9:08 PM, Christian Müller < > christian.muel...@gmail.com> wrote: > > > By the way, I got this exception too in my unit tests using the Aries > > TransactionManager (version 0.3) and ActiveMq 5.5-SNAPSHOT. I will have a > > second look at it and may reopen this issue. > > > > Best, > > Christian > > > > > > On Thu, Apr 19, 2012 at 2:36 PM, DEPREZ Arnaud AWL-IT < > > arnaud.dep...@atos.net> wrote: > > > >> Hi again Chris, > >> > >> Can you also tell me what did you do to setup ActiveMQ 5.6 SNAPSHOT ? > >> If you use ServiceMix : > >> Did you remove the previous from ServiceMix and install this one ? > >> Did you simply install the new versions of ActiveMQ and let the other > >> libraries live in parallel ? > >> Can you provide the list of dependencies you use ? Or the features ? > >> > >> > >> Arnaud Deprez > >> > >> please don't print unless you really need to > >> > >> > >> -----Original Message----- > >> From: DEPREZ Arnaud AWL-IT > >> Sent: jeudi 19 avril 2012 14:24 > >> To: users@camel.apache.org > >> Subject: RE: OSGI Transaction Propagation to Camel Route > >> > >> Hi Chris, > >> > >> Concerning your question, I don't really understand the meaning. > >> Can you give me more details ? > >> > >> By the way, does anybody have an idea about when the 5.6 official > release > >> comes out ? > >> Actually, I get exactly the same problem with the XA transactionManager > >> from Aries and ActiveMQ and I don't want to use the snapshot version. > >> > >> Here is my log for more details : > >> > >> 14:23:04,801 | WARN | tenerContainer-1 | PooledSession > >> | 47 - org.apache.activemq.activemq-pool - 5.4.2.fuse-04-05 | Caught > >> exception trying rollback() when putting session back into the pool: > >> javax.jms.TransactionInProgressException: Cannot rollback() inside an > >> XASession > >> javax.jms.TransactionInProgressException: Cannot rollback() inside an > >> XASession > >> at > >> > org.apache.activemq.ActiveMQXASession.rollback(ActiveMQXASession.java:76)[43:org.apache.activemq.activemq-core:5.4.2.fuse-04-05] > >> at > >> > org.apache.activemq.pool.PooledSession.close(PooledSession.java:111)[47:org.apache.activemq.activemq-pool:5.4.2.fuse-04-05] > >> at > >> > org.springframework.jms.support.JmsUtils.closeSession(JmsUtils.java:108)[77:org.springframework.jms:3.0.5.RELEASE] > >> at > >> > org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:366)[77:org.springframework.jms:3.0.5.RELEASE] > >> at > >> > org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)[77:org.springframework.jms:3.0.5.RELEASE] > >> at > >> > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)[77:org.springframework.jms:3.0.5.RELEASE] > >> at > >> > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)[77:org.springframework.jms:3.0.5.RELEASE] > >> at > >> > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)[77:org.springframework.jms:3.0.5.RELEASE] > >> at java.lang.Thread.run(Thread.java:619)[:1.6.0_14] > >> > >> > >> Arnaud Deprez > >> > >> please don't print unless you really need to > >> > >> -----Original Message----- > >> From: Chris Geer [mailto:ch...@cxtsoftware.com] > >> Sent: mercredi 18 avril 2012 18:43 > >> To: users@camel.apache.org > >> Subject: Re: OSGI Transaction Propagation to Camel Route > >> > >> After an upgrade to 5.6-SNAPSHOT everything works as expected. I'm still > >> curious about my last question though :) > >> > >> Thank you all for your help. > >> > >> Chris > >> > >> On Tue, Apr 17, 2012 at 6:28 PM, Chris Geer <ch...@cxtsoftware.com> > >> wrote: > >> > >> > Thanks Raul, that issue does look like the problem I'm seeing on the > >> > success case. I'll try and upgrade to 5.6-SNAPSHOT tomorrow and see if > >> that > >> > resolves the issue. > >> > > >> > I now see that I need to have a XA Connection Factory and XA > Connection > >> > Pool for Camel to be able to integrate with a XA transaction. What I > >> don't > >> > understand is why I'm able to, in code, take a connection from a > normal > >> > connection factory/pool, that is configured with a transaction manager > >> and > >> > has a ResourceManager associated with it, and enlist it in a XA > >> transaction > >> > but that same setup won't work with Camel. I'm sure there is a good > >> reason, > >> > I just don't understand why. Any thoughts? > >> > > >> > Here is my normal ActiveMQ setup that works with XA transactions from > >> code. > >> > > >> > <bean id="activemqConnectionFactory" > >> > class="org.apache.activemq.ActiveMQConnectionFactory"> > >> > <property name="brokerURL" > >> > value="vm://default?create=false&waitForStart=10000" /> > >> > </bean> > >> > > >> > <bean id="pooledConnectionFactory" > >> > class="org.apache.activemq.pool.PooledConnectionFactory"> > >> > <property name="maxConnections" value="8" /> > >> > <property name="connectionFactory" > >> ref="activemqConnectionFactory" > >> > /> > >> > </bean> > >> > > >> > <bean id="resourceManager" > >> > class="org.apache.activemq.pool.ActiveMQResourceManager" > >> > init-method="recoverResource"> > >> > <property name="transactionManager" ref="transactionManager" > >> /> > >> > <property name="connectionFactory" > >> > ref="activemqConnectionFactory" /> > >> > <property name="resourceName" value="activemq.default" /> > >> > </bean> > >> > > >> > <reference id="transactionManager" > >> > interface="javax.transaction.TransactionManager" /> > >> > > >> > <service ref="pooledConnectionFactory" > >> > interface="javax.jms.ConnectionFactory"> > >> > <service-properties> > >> > <entry key="name" value="localhost"/> > >> > </service-properties> > >> > </service> > >> > > >> > Thanks again for helping me out, I appreciate it, > >> > Chris > >> > > >> > > >> > On Tue, Apr 17, 2012 at 4:36 PM, Raul Kripalani <r...@fusesource.com > >> >wrote: > >> > > >> >> Also, see https://issues.apache.org/jira/browse/AMQ-3251. > >> >> > >> >> I think the fix was backported to a release of Fuse ESB 4.4.1, that's > >> >> why we don't experience it in the example. > >> >> > >> >> You may want to try with a Fuse ESB release if using an AMQ snapshot > >> >> is not an option for you. > >> >> > >> >> Regards, > >> >> Raul. > >> >> > >> >> On 18 Apr 2012, at 00:28, Raul Kripalani <r...@fusesource.com> > wrote: > >> >> > >> >> > I noticed you are using PROPAGATION_MANDATORY, which will throw an > >> >> > exception if a transaction doesn't already exist. Could that > justify > >> >> > the exception you see when isolating only Camel? Can you try with > >> >> > PROPAGATION_REQUIRED instead? > >> >> > > >> >> > The sample I pointed you to works with no changes. In fact, you may > >> >> > want to try it out locally substituting the DB interactions with > >> >> > another JMS send... > >> >> > > >> >> > Thanks. > >> >> > > >> >> > On 17 Apr 2012, at 22:21, Chris Geer <ch...@cxtsoftware.com> > wrote: > >> >> > > >> >> >> The only place I'm not using an already XA aware connection > factory > >> is > >> >> in > >> >> >> the API side, which is working perfectly because I'm manually > >> >> enlisting the > >> >> >> Session. > >> >> >> > >> >> >> On the camel side, I used your example exactly as you can see in > my > >> >> >> blueprint file and everything depends on XA aware activemq > objects. > >> >> Just to > >> >> >> make sure the API side of things wasn't interfering with the camel > >> part > >> >> >> (which would be odd), I commented out all the code except for the > >> camel > >> >> >> send and commented out the reference to the standard JMS > Connection > >> >> >> Factory. Even with those drastic measures, I still got all the > same > >> >> errors > >> >> >> even though the camel route was the only participant in the > >> transaction > >> >> >> along with the OSGI component itself. > >> >> >> > >> >> >> What was the change you made to get it working without errors? > >> >> >> > >> >> >> Chris > >> >> >> > >> >> >> On Tue, Apr 17, 2012 at 1:48 PM, Raul Kripalani < > >> r...@fusesource.com> > >> >> wrote: > >> >> >> > >> >> >>> It looks like you may not be using an XA-aware Pooled Connection > >> >> Factory :D > >> >> >>> > >> >> >>> See > >> >> >>> > >> >> > >> > http://activemq.apache.org/maven/5.5.0/activemq-pool/apidocs/org/apache/activemq/pool/XaPooledConnectionFactory.html > >> >> >>> > >> >> >>> It may look catchy, but all the layers of the stack need to be > >> >> >>> XA-aware, as XA requires a different behaviour when handling > >> borrowing > >> >> >>> and returning to the pool. > >> >> >>> > >> >> >>> Let me know if it works for you. > >> >> >>> > >> >> >>> Regards, > >> >> >>> Raul. > >> >> >>> > >> >> >>> On 17 Apr 2012, at 18:31, Chris Geer <ch...@cxtsoftware.com> > >> wrote: > >> >> >>> > >> >> >>>> Raul, > >> >> >>>> > >> >> >>>> Thanks for the information. I tried what you said and I think it > >> did > >> >> have > >> >> >>>> some success with rolling back the transaction but it causes > >> >> significant > >> >> >>>> errors to be thrown during a success case. As I've written a > >> sample > >> >> to > >> >> >>>> debug this issue I wanted you to have my latest code so we can > be > >> >> >>>> referencing the same thing if you're willing to take another > look. > >> >> >>>> > >> >> >>>> README: http://pastebin.com/UWq3yk4c > >> >> >>>> OSGI Implementation: http://pastebin.com/ifQTybn3 > >> >> >>>> OSGI Interface: http://pastebin.com/zEUP8jJJ > >> >> >>>> Blueprint File: http://pastebin.com/sxBtxNCq > >> >> >>>> Test Driver/Logger: http://pastebin.com/SDVFvjGm > >> >> >>>> pom.xml: http://pastebin.com/kTXXaebV > >> >> >>>> > >> >> >>>> Part of the error I'm seeing is this (commit -> rollback) > >> >> >>>> > >> >> >>>> 10:12:52,624 | WARN | 52 - timer://foo | PooledSession > >> >> >>>> | 57 - org.apache.activemq.activemq-pool - 5.5.1 | Caught > >> exception > >> >> >>> trying > >> >> >>>> rollback() when putting session back into the pool: > >> >> >>>> javax.jms.TransactionInProgressException: Cannot rollback() > >> inside an > >> >> >>>> XASession > >> >> >>>> javax.jms.TransactionInProgressException: Cannot rollback() > >> inside an > >> >> >>>> XASession > >> >> >>>> at > >> >> >>>> > >> >> >>> > >> >> > >> > org.apache.activemq.ActiveMQXASession.rollback(ActiveMQXASession.java:76)[60:org.apache.activemq.activemq-core:5.5.1] > >> >> >>>> at > >> >> >>>> > >> >> >>> > >> >> > >> > org.apache.activemq.pool.PooledSession.close(PooledSession.java:111)[57:org.apache.activemq.activemq-pool:5.5.1] > >> >> >>>> at > >> >> >>>> > >> >> >>> > >> >> > >> > org.apache.activemq.pool.XaConnectionPool$Synchronization.afterCompletion(XaConnectionPool.java:90)[57:org.apache.activemq.activemq-pool:5.5.1] > >> >> >>>> at > >> >> >>>> > >> >> >>> > >> >> > >> > org.apache.geronimo.transaction.manager.TransactionImpl.afterCompletion(TransactionImpl.java:540)[45:org.apache.aries.transaction.manager:0.3.0] > >> >> >>>> at > >> >> >>>> > >> >> >>> > >> >> > >> > org.apache.geronimo.transaction.manager.TransactionImpl.afterCompletion(TransactionImpl.java:533)[45:org.apache.aries.transaction.manager:0.3.0] > >> >> >>>> at > >> >> >>>> > >> >> >>> > >> >> > >> > org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:329)[45:org.apache.aries.transaction.manager:0.3.0] > >> >> >>>> at > >> >> >>>> > >> >> >>> > >> >> > >> > org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)[45:org.apache.aries.transaction.manager:0.3.0] > >> >> >>>> > >> >> >>>> > >> >> >>>> Chris > >> >> >>>> > >> >> >>>> On Tue, Apr 17, 2012 at 9:44 AM, Raul Kripalani < > >> r...@fusesource.com > >> >> > > >> >> >>> wrote: > >> >> >>>> > >> >> >>>>> I noticed several things in your config. > >> >> >>>>> > >> >> >>>>> 1) the JMS config should be inside the 'configuration' property > >> of > >> >> the > >> >> >>>>> ActiveMQComponent: > >> >> >>>>> > >> >> >>>>> <!-- ActiveMQ JMS Configuration is defined as Transacted and > >> >> leverages > >> >> >>> XA > >> >> >>>>> Transactions --> > >> >> >>>>> <bean id="activemq" > >> >> >>>>> class="org.apache.activemq.camel.component.ActiveMQComponent"> > >> >> >>>>> <property name="configuration"> > >> >> >>>>> <bean > class="org.apache.camel.component.jms.JmsConfiguration"> > >> >> >>>>> <property name="connectionFactory" > >> >> >>>>> ref="pooledConnectionFactoryXa"/> > >> >> >>>>> <property name="transactionManager" > ref="platformTxManager" > >> /> > >> >> >>>>> <property name="transacted" value="false"/> > >> >> >>>>> <property name="cacheLevelName" value="CACHE_NONE"/> > >> >> >>>>> </bean> > >> >> >>>>> </property> > >> >> >>>>> </bean> > >> >> >>>>> > >> >> >>>>> 2) the 'transacted' property should be false as above, because > >> you > >> >> don't > >> >> >>>>> want the component to manage the transactions locally. The > >> >> enrolment of > >> >> >>>>> resources and coordination of transaction will happen on the XA > >> >> level. > >> >> >>>>> > >> >> >>>>> 3) you are missing the ActiveMQResourceManager, which needs an > >> >> >>> injection of > >> >> >>>>> a javax.transaction.TransactionManager, which in reality is the > >> >> same as > >> >> >>> the > >> >> >>>>> PlatformTransactionManager, but you under a different interface > >> >> >>>>> > >> >> >>>>> See the following link for how your config should look like: > >> >> >>>>> > >> >> >>>>> > >> >> >>> > >> >> > >> > https://github.com/FuseByExample/camel-persistence-part2/blob/master/route-one-tx-manager/src/main/resources/META-INF/spring/springConfig.xml > >> >> >>>>> . > >> >> >>>>> > >> >> >>>>> And of course, the route must be invoked from the same thread > >> where > >> >> the > >> >> >>>>> transaction is being started, and you cannot use the SEDA > >> component > >> >> for > >> >> >>>>> that. You must invoke it via a direct endpoint and I think > >> >> >>>>> requestBodyAndHeader(), but I'm not sure about this last point. > >> >> >>>>> > >> >> >>>>> Regards, > >> >> >>>>> > >> >> >>>>> *Raúl Kripalani* > >> >> >>>>> Principal Consultant | FuseSource Corp. > >> >> >>>>> r...@fusesource.com | fusesource.com < > http://www.fusesource.com/ > >> > > >> >> >>> skype: > >> >> >>>>> raul.fuse | twitter: @raulvk <http://twitter.com/raulvk>, > >> >> >>>>> @fusenews<http://twitter.com/fusenews> > >> >> >>>>> > >> >> >>>>> <http://twitter.com/fusenews> > >> >> >>>>> > >> >> >>>>> On 17 April 2012 16:53, Chris Geer <ch...@cxtsoftware.com> > >> wrote: > >> >> >>>>> > >> >> >>>>>> Raul, > >> >> >>>>>> > >> >> >>>>>> I gave that a shot but it actually made the problem worse. > >> >> >>>>>> ProducerTemplate.requestBodyAndHeader uses an InOut exchange > >> >> pattern > >> >> >>> but > >> >> >>>>>> since I'm not sending responses it always fails (regardless of > >> >> >>>>> transaction) > >> >> >>>>>> with a timeout saying it didn't get a response. It also send > the > >> >> >>> message > >> >> >>>>> to > >> >> >>>>>> the topic even without the transaction being committed so it > >> >> wouldn't > >> >> >>>>> solve > >> >> >>>>>> the transaction problem anyway. > >> >> >>>>>> > >> >> >>>>>> Chris > >> >> >>>>>> > >> >> >>>>>> On Tue, Apr 17, 2012 at 1:47 AM, Raul Kripalani < > >> >> r...@fusesource.com> > >> >> >>>>>> wrote: > >> >> >>>>>> > >> >> >>>>>>> Hi Chris! > >> >> >>>>>>> > >> >> >>>>>>> Transaction Managers bind transactions to threads, and a > >> possible > >> >> >>> cause > >> >> >>>>>> for > >> >> >>>>>>> your transaction getting lost is that your route is being > >> called > >> >> >>>>>>> asynchronously from another thread. > >> >> >>>>>>> > >> >> >>>>>>> This is because you are using ProducerTemplate.send...(). > >> >> >>>>>>> > >> >> >>>>>>> Can you replace this with > >> >> ProducerTemplate.requestBodyAndHeader(...), > >> >> >>>>>> which > >> >> >>>>>>> in theory should call the route synchronously in the same > >> thread? > >> >> >>>>>>> > >> >> >>>>>>> Regards, > >> >> >>>>>>> > >> >> >>>>>>> *Raúl Kripalani* > >> >> >>>>>>> Principal Consultant | FuseSource Corp. > >> >> >>>>>>> r...@fusesource.com | fusesource.com < > >> http://www.fusesource.com/> > >> >> >>>>> skype: > >> >> >>>>>>> raul.fuse | twitter: @raulvk <http://twitter.com/raulvk>, > >> >> >>>>>>> @fusenews<http://twitter.com/fusenews> > >> >> >>>>>>> > >> >> >>>>>>> <http://twitter.com/fusenews> > >> >> >>>>>>> > >> >> >>>>>>> On 16 April 2012 23:09, Chris Geer <ch...@cxtsoftware.com> > >> wrote: > >> >> >>>>>>> > >> >> >>>>>>>> Claus, > >> >> >>>>>>>> > >> >> >>>>>>>> I'm still struggling with this so I've put together a quick > >> >> sample > >> >> >>>>>>> project > >> >> >>>>>>>> that shows the problem. It consists of an OSGI component > that > >> >> runs > >> >> >>>>>> under > >> >> >>>>>>> a > >> >> >>>>>>>> transaction and posts two JMS messages (one with Camel and > one > >> >> with > >> >> >>>>> JMS > >> >> >>>>>>>> APIs) then rolls back the transactions. I would hope to see > >> both > >> >> >>>>>> messages > >> >> >>>>>>>> not be delivered but instead what I see if the one sent via > >> camel > >> >> >>>>> being > >> >> >>>>>>>> delivered while the other one is rolled back. I'm sure I'm > >> >> probably > >> >> >>>>>> doing > >> >> >>>>>>>> something wrong but I can't figure it out. > >> >> >>>>>>>> > >> >> >>>>>>>> Is there a place I can post my sample project where someone > >> >> might be > >> >> >>>>>> able > >> >> >>>>>>>> to give it a quick look? > >> >> >>>>>>>> > >> >> >>>>>>>> Thanks, > >> >> >>>>>>>> Chris > >> >> >>>>>>>> > >> >> >>>>>>>> On Sat, Apr 7, 2012 at 3:19 AM, Claus Ibsen < > >> >> claus.ib...@gmail.com> > >> >> >>>>>>> wrote: > >> >> >>>>>>>> > >> >> >>>>>>>>> On Thu, Apr 5, 2012 at 5:57 PM, Chris Geer < > >> >> ch...@cxtsoftware.com> > >> >> >>>>>>>> wrote: > >> >> >>>>>>>>>> Claus, > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> I realize that but I can't explain what I'm seeing. Here > is > >> an > >> >> >>>>>>>> additional > >> >> >>>>>>>>>> piece of info, here is debug log for the sending of the > >> >> message. > >> >> >>>>> As > >> >> >>>>>>> you > >> >> >>>>>>>>> can > >> >> >>>>>>>>>> see, the transaction fields are all null but I don't know > if > >> >> that > >> >> >>>>>> is > >> >> >>>>>>>>> normal > >> >> >>>>>>>>>> or a symptom of the problem. > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> 08:51:22,906 | DEBUG | erations/address | JmsConfiguration > >> >> >>>>>>>>>> | 169 - org.apache.camel.camel-jms - 2.9.2.SNAPSHOT | > >> Sending > >> >> JMS > >> >> >>>>>>>> message > >> >> >>>>>>>>>> to: topic://event-notifications with message: > >> >> >>>>> ActiveMQBytesMessage > >> >> >>>>>>>>>> {commandId = 0, responseRequired = false, messageId = > null, > >> >> >>>>>>>>>> originalDestination = null, originalTransactionId = null, > >> >> >>>>>> producerId > >> >> >>>>>>> = > >> >> >>>>>>>>>> null, destination = null, transactionId = null, expiration > >> = 0, > >> >> >>>>>>>>> timestamp = > >> >> >>>>>>>>>> 0, arrival = 0, brokerInTime = 0, brokerOutTime = 0, > >> >> >>>>> correlationId > >> >> >>>>>> = > >> >> >>>>>>>>> null, > >> >> >>>>>>>>>> replyTo = null, persistent = true, type = null, priority = > >> 0, > >> >> >>>>>>> groupID = > >> >> >>>>>>>>>> null, groupSequence = 0, targetConsumerId = null, > >> compressed = > >> >> >>>>>> false, > >> >> >>>>>>>>>> userID = null, content = null, marshalledProperties = > null, > >> >> >>>>>>>>> dataStructure = > >> >> >>>>>>>>>> null, redeliveryCounter = 0, size = 0, properties = > >> >> >>>>>>>> {EntityType=Address, > >> >> >>>>>>>>>> > breadcrumbId=ID-CXTMBP-Chris-local-62052-1333577461603-22-3, > >> >> >>>>>>>>>> EventType=EntityCreated, ClientID=0}, readOnlyProperties = > >> >> false, > >> >> >>>>>>>>>> readOnlyBody = false, droppable = false} > >> ActiveMQBytesMessage{ > >> >> >>>>>>>> bytesOut = > >> >> >>>>>>>>>> org.apache.activemq.util.ByteArrayOutputStream@51762faf, > >> >> >>>>> dataOut = > >> >> >>>>>>>>>> java.io.DataOutputStream@2634b3f1, dataIn = null } > >> >> >>>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>>> I would only suspect transaction ids being populated in the > >> AMQ > >> >> >>>>>>>>> message if the message originated from the AMQ broker. > >> Creating > >> >> a > >> >> >>>>> new > >> >> >>>>>>>>> message to be send would most likely not populate TX ids > and > >> >> >>>>> whatnot. > >> >> >>>>>>>>> But the work is still carried out under the TX manager. (if > >> TX > >> >> is > >> >> >>>>>>>>> properly configured and working - yeah thats the hard > part). > >> >> >>>>>>>>> > >> >> >>>>>>>>>> Here is more of the stack trace that shows the transaction > >> >> being > >> >> >>>>>>>>> committed > >> >> >>>>>>>>>> for some reason. > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> 08:51:22,888 | DEBUG | erations/address | > >> >> TransactionErrorHandler > >> >> >>>>>>>>>> | 166 - org.apache.camel.camel-core - 2.9.2.SNAPSHOT | > >> >> >>>>> Transaction > >> >> >>>>>>>> begin > >> >> >>>>>>>>>> (0x1f2198ab) redelivered(unknown) for (MessageId: > >> >> >>>>>>>>>> ID-CXTMBP-Chris-local-62052-1333577461603-22-3 on > >> ExchangeId: > >> >> >>>>>>>>>> ID-CXTMBP-Chris-local-62052-1333577461603-22-4)) > >> >> >>>>>>>>>> 08:51:22,888 | DEBUG | erations/address | > >> JtaTransactionManager > >> >> >>>>>>>>>> | 139 - org.springframework.transaction - 3.0.6.RELEASE | > >> >> >>>>>>>> Participating > >> >> >>>>>>>>> in > >> >> >>>>>>>>>> existing transaction > >> >> >>>>>>>>>> 08:51:22,906 | DEBUG | erations/address | JmsConfiguration > >> >> >>>>>>>>>> | 169 - org.apache.camel.camel-jms - 2.9.2.SNAPSHOT | > >> Sending > >> >> JMS > >> >> >>>>>>>> message > >> >> >>>>>>>>>> to: topic://event-notifications with message: > >> >> >>>>> ActiveMQBytesMessage > >> >> >>>>>>>>>> {commandId = 0, responseRequired = false, messageId = > null, > >> >> >>>>>>>>>> originalDestination = null, originalTransactionId = null, > >> >> >>>>>> producerId > >> >> >>>>>>> = > >> >> >>>>>>>>>> null, destination = null, transactionId = null, expiration > >> = 0, > >> >> >>>>>>>>> timestamp = > >> >> >>>>>>>>>> 0, arrival = 0, brokerInTime = 0, brokerOutTime = 0, > >> >> >>>>> correlationId > >> >> >>>>>> = > >> >> >>>>>>>>> null, > >> >> >>>>>>>>>> replyTo = null, persistent = true, type = null, priority = > >> 0, > >> >> >>>>>>> groupID = > >> >> >>>>>>>>>> null, groupSequence = 0, targetConsumerId = null, > >> compressed = > >> >> >>>>>> false, > >> >> >>>>>>>>>> userID = null, content = null, marshalledProperties = > null, > >> >> >>>>>>>>> dataStructure = > >> >> >>>>>>>>>> null, redeliveryCounter = 0, size = 0, properties = > >> >> >>>>>>>> {EntityType=Address, > >> >> >>>>>>>>>> > breadcrumbId=ID-CXTMBP-Chris-local-62052-1333577461603-22-3, > >> >> >>>>>>>>>> EventType=EntityCreated, ClientID=0}, readOnlyProperties = > >> >> false, > >> >> >>>>>>>>>> readOnlyBody = false, droppable = false} > >> ActiveMQBytesMessage{ > >> >> >>>>>>>> bytesOut = > >> >> >>>>>>>>>> org.apache.activemq.util.ByteArrayOutputStream@51762faf, > >> >> >>>>> dataOut = > >> >> >>>>>>>>>> java.io.DataOutputStream@2634b3f1, dataIn = null } > >> >> >>>>>>>>>> 08:51:22,907 | DEBUG | erations/address | > >> JtaTransactionManager > >> >> >>>>>>>>>> | 139 - org.springframework.transaction - 3.0.6.RELEASE | > >> >> >>>>>>> Registering > >> >> >>>>>>>>>> after-completion synchronization with existing JTA > >> transaction > >> >> >>>>>>>>>> 08:51:22,907 | DEBUG | erations/address | > >> >> TransactionErrorHandler > >> >> >>>>>>>>>> | 166 - org.apache.camel.camel-core - 2.9.2.SNAPSHOT | > >> >> >>>>> Transaction > >> >> >>>>>>>>> commit > >> >> >>>>>>>>>> (0x1f2198ab) redelivered(unknown) for (MessageId: > >> >> >>>>>>>>>> ID-CXTMBP-Chris-local-62052-1333577461603-22-3 on > >> ExchangeId: > >> >> >>>>>>>>>> ID-CXTMBP-Chris-local-62052-1333577461603-22-4)) > >> >> >>>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>>> That last debug logging is just Camel saying that the TX > >> >> completed > >> >> >>>>>>>>> successfully (in that leg). Its up to the TX manager when > >> >> actually > >> >> >>>>> to > >> >> >>>>>>>>> commit the TX. If a TX was started outside, then the commit > >> is > >> >> >>>>>>>>> executed at that point. > >> >> >>>>>>>>> > >> >> >>>>>>>>> So this is normal. > >> >> >>>>>>>>> > >> >> >>>>>>>>>> On Thu, Apr 5, 2012 at 8:19 AM, Claus Ibsen < > >> >> >>>>> claus.ib...@gmail.com > >> >> >>>>>>> > >> >> >>>>>>>>> wrote: > >> >> >>>>>>>>>> > >> >> >>>>>>>>>>> On Thu, Apr 5, 2012 at 4:59 PM, Chris Geer < > >> >> >>>>> ch...@cxtsoftware.com > >> >> >>>>>>> > >> >> >>>>>>>>> wrote: > >> >> >>>>>>>>>>>> Christian, > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> I have that book and that is what I used for a lot of my > >> >> >>>>>>> reference. > >> >> >>>>>>>> In > >> >> >>>>>>>>>>>> fact, they only major difference between his source and > >> mine > >> >> >>>>> is > >> >> >>>>>> he > >> >> >>>>>>>> is > >> >> >>>>>>>>>>> using > >> >> >>>>>>>>>>>> Atomikos as the transaction manager and I'm using aries. > >> I am > >> >> >>>>>>>>> referencing > >> >> >>>>>>>>>>>> an existing PlatformTransactionManager instead of > >> creating a > >> >> >>>>>>>>>>>> JtaTransactionManager but PlatformTransactionManager > >> >> >>>>> implements > >> >> >>>>>>>>>>>> JtaTransactionManager so it should be ok. > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> As for the datasource, I'm actually publishing it from > >> >> another > >> >> >>>>>>> OSGI > >> >> >>>>>>>>>>>> component as a service so it can be reused. I'm creating > >> it > >> >> in > >> >> >>>>>>> code > >> >> >>>>>>>>> right > >> >> >>>>>>>>>>>> now as defined below. > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> BasicManagedDataSource ds = new > >> >> >>>>> BasicManagedDataSource(); > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> if(xaDataSourceClass != null && > >> >> >>>>>>>> !xaDataSourceClass.isEmpty()) { > >> >> >>>>>>>>>>>> try { > >> >> >>>>>>>>>>>> XADataSource dsi = > >> >> >>>>>>>>>>>> > >> (XADataSource)Class.forName(xaDataSourceClass).newInstance(); > >> >> >>>>>>>>>>>> Method setUrl = > >> >> >>>>>> dsi.getClass().getMethod("setUrl", > >> >> >>>>>>>> new > >> >> >>>>>>>>>>>> Class[] {String.class}); > >> >> >>>>>>>>>>>> setUrl.invoke(dsi, (String) > >> >> >>>>>>> config.get(CONNSTR_KEY)); > >> >> >>>>>>>>>>>> ds.setXADataSource(xaDataSourceClass); > >> >> >>>>>>>>>>>> ds.setXaDataSourceInstance(dsi); > >> >> >>>>>>>>>>>> } catch (IllegalArgumentException ex) { > >> >> >>>>>>>>>>>> throw new > >> >> >>>>>>> ConfigurationException("xaDataSourceClass", > >> >> >>>>>>>>>>>> "Couldn't create instance", ex); > >> >> >>>>>>>>>>>> } catch (InvocationTargetException ex) { > >> >> >>>>>>>>>>>> throw new > >> >> >>>>>>> ConfigurationException("xaDataSourceClass", > >> >> >>>>>>>>>>>> "Couldn't create instance", ex); > >> >> >>>>>>>>>>>> } catch (NoSuchMethodException ex) { > >> >> >>>>>>>>>>>> throw new > >> >> >>>>>>> ConfigurationException("xaDataSourceClass", > >> >> >>>>>>>>>>>> "Couldn't create instance", ex); > >> >> >>>>>>>>>>>> } catch (SecurityException ex) { > >> >> >>>>>>>>>>>> throw new > >> >> >>>>>>> ConfigurationException("xaDataSourceClass", > >> >> >>>>>>>>>>>> "Couldn't create instance", ex); > >> >> >>>>>>>>>>>> } catch (InstantiationException ex) { > >> >> >>>>>>>>>>>> throw new > >> >> >>>>>>> ConfigurationException("xaDataSourceClass", > >> >> >>>>>>>>>>>> "Couldn't create instance", ex); > >> >> >>>>>>>>>>>> } catch (IllegalAccessException ex) { > >> >> >>>>>>>>>>>> throw new > >> >> >>>>>>> ConfigurationException("xaDataSourceClass", > >> >> >>>>>>>>>>>> "Couldn't create instance", ex); > >> >> >>>>>>>>>>>> } catch (ClassNotFoundException ex) { > >> >> >>>>>>>>>>>> throw new > >> >> >>>>>>> ConfigurationException("xaDataSourceClass", > >> >> >>>>>>>>>>>> "Class not found", ex); > >> >> >>>>>>>>>>>> } > >> >> >>>>>>>>>>>> } else { > >> >> >>>>>>>>>>>> ds.setDriverClassName((String) > >> >> >>>>>> config.get(DRIVER_KEY)); > >> >> >>>>>>>>>>>> ds.setUrl((String) config.get(CONNSTR_KEY)); > >> >> >>>>>>>>>>>> } > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> BundleContext context = > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>> > >> >> >>>>>> > >> >> >>>>> > >> >> >>> > >> >> > >> > FrameworkUtil.getBundle(BedrockConnectionPoolFactory.class).getBundleContext(); > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> ds.setTransactionManager(transMgr); > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> Hashtable<String, String> sp = new Hashtable<String, > >> >> >>>>>>>> String>(); > >> >> >>>>>>>>>>>> sp.put(DSNAME_KEY, (String) config.get(DSNAME_KEY)); > >> >> >>>>>>>>>>>> ServiceRegistration reg = > >> >> >>>>>>>>>>>> context.registerService("javax.sql.XADataSource", > >> >> >>>>>>>>>>>> ds.getXaDataSourceInstance(), sp); > >> >> >>>>>>>>>>>> regMap.put(id, reg); > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> The transMgr variable above is looking up the Aries > >> >> >>>>> transaction > >> >> >>>>>>>>> manager > >> >> >>>>>>>>>>>> deployed in SMX (same one my JMS code is getting through > >> the > >> >> >>>>>>>>>>>> PlatformTransactionManager interface). > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> The biggest challenge I've had is that every single > camel > >> >> >>>>>>>> transaction > >> >> >>>>>>>>>>>> example I've seen starts the transaction INSIDE camel. > >> They > >> >> >>>>> all > >> >> >>>>>>>>> resemble > >> >> >>>>>>>>>>>> the diagram on page 300 of Claus' book. I haven't seen > any > >> >> >>>>>> example > >> >> >>>>>>>>> where > >> >> >>>>>>>>>>>> camel is enlisted in an already existing transaction. I > >> was > >> >> >>>>>> hoping > >> >> >>>>>>>>> that > >> >> >>>>>>>>>>> was > >> >> >>>>>>>>>>>> just because examples are traditionally simple but maybe > >> it > >> >> >>>>>> wasn't > >> >> >>>>>>>>>>> designed > >> >> >>>>>>>>>>>> to do that? > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>> > >> >> >>>>>>>>>>> Camel does not have its own TX manager etc. All we do is > to > >> >> hook > >> >> >>>>>>> into > >> >> >>>>>>>>>>> the Spring TX manager. > >> >> >>>>>>>>>>> So if there is already a TX in progress, then Camel > should > >> >> just > >> >> >>>>>> play > >> >> >>>>>>>>>>> along, and run in that same TX. > >> >> >>>>>>>>>>> > >> >> >>>>>>>>>>> The Camel processing occurs in a Spring TX template in > its > >> - > >> >> >>>>>>>>>>> doInTransaction method. That happens when you use the > >> >> >>>>> <transacted> > >> >> >>>>>>> in > >> >> >>>>>>>>>>> the Route. > >> >> >>>>>>>>>>> > >> >> >>>>>>>>>>>> Chris > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> On Thu, Apr 5, 2012 at 1:11 AM, Christian Müller < > >> >> >>>>>>>>>>>> christian.muel...@gmail.com> wrote: > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>>> Chris, > >> >> >>>>>>>>>>>>> may be the source code of Claus book "Camel in Action" > is > >> >> >>>>>> helpful > >> >> >>>>>>>> for > >> >> >>>>>>>>>>> you > >> >> >>>>>>>>>>>>> [1]. > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> Could you als share your datasource configuration with > >> us? > >> >> It > >> >> >>>>>> was > >> >> >>>>>>>>> not in > >> >> >>>>>>>>>>>>> your post... > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> [1] > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>> > >> >> >>>>>> > >> >> >>>>> > >> >> >>> > >> >> > >> > http://code.google.com/p/camelinaction/source/browse/trunk/chapter9/xa/src/test/resources/spring-context.xml > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> Best, > >> >> >>>>>>>>>>>>> Christian > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> On Thu, Apr 5, 2012 at 7:13 AM, Chris Geer < > >> >> >>>>>>> ch...@cxtsoftware.com> > >> >> >>>>>>>>>>> wrote: > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> We are building an application using ServiceMix (CXF, > >> >> >>>>> Camel, > >> >> >>>>>>>>> Karaf...) > >> >> >>>>>>>>>>>>> and > >> >> >>>>>>>>>>>>>> we've run into an issue with transactions not > >> propagating > >> >> >>>>> to > >> >> >>>>>>>> camel > >> >> >>>>>>>>>>> routes > >> >> >>>>>>>>>>>>>> as we'd like them to. We have several OSGI components > >> that > >> >> >>>>>> run > >> >> >>>>>>>>> under > >> >> >>>>>>>>>>>>>> transactions using the Aries transaction management > like > >> >> >>>>> the > >> >> >>>>>>>>>>> following: > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> <bean id="serviceBean" class="<class>"> > >> >> >>>>>>>>>>>>>> <property name="dataSource" ref="ds"/> > >> >> >>>>>>>>>>>>>> <property name="camelContext" ref="camelCtx"/> > >> >> >>>>>>>>>>>>>> <tx:transaction method="updateAddress, > >> >> >>>>> createAddress, > >> >> >>>>>>>>>>>>>> deleteAddress" value="Required" /> > >> >> >>>>>>>>>>>>>> <tx:transaction method="getAddress, findAddresses" > >> >> >>>>>>>>>>>>> value="Supports" > >> >> >>>>>>>>>>>>>> /> > >> >> >>>>>>>>>>>>>> </bean> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> We have published a DataSource which is transaction > >> aware > >> >> >>>>> for > >> >> >>>>>>> our > >> >> >>>>>>>>>>>>>> components to use. It shows up in SMX as the > following: > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> aries.xa.aware = true > >> >> >>>>>>>>>>>>>> dsName = ds > >> >> >>>>>>>>>>>>>> objectClass = javax.sql.DataSource > >> >> >>>>>>>>>>>>>> service.id = 298 > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> In our components we are able to perform database > >> >> >>>>>> transactions > >> >> >>>>>>>> that > >> >> >>>>>>>>>>>>>> successfully get committed/rolled back as expected > >> without > >> >> >>>>>>> having > >> >> >>>>>>>>> to > >> >> >>>>>>>>>>>>>> manually enlist the JDBC connection. It works great. > >> Those > >> >> >>>>>> same > >> >> >>>>>>>>>>>>> components > >> >> >>>>>>>>>>>>>> also will send various JMS messages as they > >> succeed/fail. > >> >> >>>>> Our > >> >> >>>>>>>> goal > >> >> >>>>>>>>> is > >> >> >>>>>>>>>>>>> that > >> >> >>>>>>>>>>>>>> if a component sends a JMS message on success and > later > >> >> >>>>> rolls > >> >> >>>>>>>> back > >> >> >>>>>>>>> the > >> >> >>>>>>>>>>>>> JMS > >> >> >>>>>>>>>>>>>> message would be retracted. If we lookup a JMS > >> >> >>>>>>> ConnectionFactory, > >> >> >>>>>>>>>>> create > >> >> >>>>>>>>>>>>> a > >> >> >>>>>>>>>>>>>> connection, session, manually enlist the session into > >> the > >> >> >>>>>>> current > >> >> >>>>>>>>>>>>>> transaction and send the message all in code it > actually > >> >> >>>>>> works > >> >> >>>>>>> as > >> >> >>>>>>>>>>>>> desired. > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> What we hope to be able to do however is to remove the > >> code > >> >> >>>>>> and > >> >> >>>>>>>> use > >> >> >>>>>>>>>>> camel > >> >> >>>>>>>>>>>>>> instead to process the message and pass it along to > the > >> JMS > >> >> >>>>>>>> topic, > >> >> >>>>>>>>> in > >> >> >>>>>>>>>>> the > >> >> >>>>>>>>>>>>>> same transaction that the OSGI component is running in > >> but > >> >> >>>>> we > >> >> >>>>>>>> can't > >> >> >>>>>>>>>>> quite > >> >> >>>>>>>>>>>>>> get it to work. Below is our latest configuration and > >> code > >> >> >>>>>> and > >> >> >>>>>>> at > >> >> >>>>>>>>> this > >> >> >>>>>>>>>>>>>> point the message posts to the topic but never rolls > >> back. > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> Blueprint File > >> >> >>>>>>>>>>>>>> <bean id="activemq" > >> >> >>>>>>>>>>>>>> > >> >> >>>>>> class="org.apache.activemq.camel.component.ActiveMQComponent"> > >> >> >>>>>>>>>>>>>> <property name="connectionFactory" > >> >> >>>>>>>>>>> ref="jmsXaConnectionFactory"/> > >> >> >>>>>>>>>>>>>> <property name="transacted" value="true"/> > >> >> >>>>>>>>>>>>>> <property name="transactionManager" > >> >> >>>>>>>>>>> ref="jmsTransactionManager"/> > >> >> >>>>>>>>>>>>>> </bean> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> <bean id="mandatory" > >> >> >>>>>>>>>>>>>> > >> >> >>>>> class="org.apache.camel.spring.spi.SpringTransactionPolicy"> > >> >> >>>>>>>>>>>>>> <property name="transactionManager" > >> >> >>>>>>>>>>> ref="jmsTransactionManager"/> > >> >> >>>>>>>>>>>>>> <property name="propagationBehaviorName" > >> >> >>>>>>>>>>>>>> value="PROPAGATION_MANDATORY"/> > >> >> >>>>>>>>>>>>>> </bean> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> <bean id="jmsXaConnectionFactory" > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>> class="org.apache.activemq.ActiveMQXAConnectionFactory"> > >> >> >>>>>>>>>>>>>> <property name="brokerURL" > >> >> >>>>>>> value="tcp://localhost:61616"/> > >> >> >>>>>>>>>>>>>> </bean> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> <reference id="jmsTransactionManager" > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>> > >> >> >>> > >> >> > >> interface="org.springframework.transaction.PlatformTransactionManager"/> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> <camel:camelContext id="camelCtx" trace="true"> > >> >> >>>>>>>>>>>>>> <camel:route> > >> >> >>>>>>>>>>>>>> <camel:from uri="direct:genEvent"/> > >> >> >>>>>>>>>>>>>> <camel:wireTap uri="direct:wireTap"/> > >> >> >>>>>>>>>>>>>> <camel:transacted ref="mandatory"/> > >> >> >>>>>>>>>>>>>> <camel:to > >> >> >>>>>> uri="activemq:topic:event-notifications"/> > >> >> >>>>>>>>>>>>>> </camel:route> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> <camel:route> > >> >> >>>>>>>>>>>>>> <camel:from uri="direct:wireTap"/> > >> >> >>>>>>>>>>>>>> <camel:to uri="log:logger?showAll=true"/> > >> >> >>>>>>>>>>>>>> </camel:route> > >> >> >>>>>>>>>>>>>> </camel:camelContext> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> Code: > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> ProducerTemplate pt = > >> >> >>>>>> camelCtx.createProducerTemplate(); > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> Map<String, Object> headers = new HashMap<String, > >> >> >>>>>>>> Object>(); > >> >> >>>>>>>>>>>>>> headers.put("EventType", eventType); > >> >> >>>>>>>>>>>>>> headers.put("ClientID", 0); > >> >> >>>>>>>>>>>>>> headers.put("EntityType", "Address"); > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> pt.sendBodyAndHeaders("direct:genEvent", > >> >> >>>>>>>>> getAddress(addressID), > >> >> >>>>>>>>>>>>>> headers); > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> Like I mentioned, the code all works in the success > case > >> >> >>>>> but > >> >> >>>>>>>>> doesn't > >> >> >>>>>>>>>>>>>> rollback the JMS message in the failure case. > Apparently > >> >> >>>>> the > >> >> >>>>>>>>>>> transaction > >> >> >>>>>>>>>>>>>> context isn't being passed on to the camel route even > >> >> >>>>> though > >> >> >>>>>>> it's > >> >> >>>>>>>>>>> using > >> >> >>>>>>>>>>>>> the > >> >> >>>>>>>>>>>>>> same transaction manager under the covers. Is that by > >> >> >>>>> design > >> >> >>>>>> or > >> >> >>>>>>>> is > >> >> >>>>>>>>>>> there > >> >> >>>>>>>>>>>>> a > >> >> >>>>>>>>>>>>>> way to make this scenario work? We'd really like to be > >> able > >> >> >>>>>> use > >> >> >>>>>>>> the > >> >> >>>>>>>>>>> camel > >> >> >>>>>>>>>>>>>> route approach so we can do more complex things than > >> what I > >> >> >>>>>>> show > >> >> >>>>>>>>> here. > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>> Thanks, > >> >> >>>>>>>>>>>>>> Chris > >> >> >>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>> > >> >> >>>>>>>>>>> > >> >> >>>>>>>>>>> > >> >> >>>>>>>>>>> -- > >> >> >>>>>>>>>>> Claus Ibsen > >> >> >>>>>>>>>>> ----------------- > >> >> >>>>>>>>>>> CamelOne 2012 Conference, May 15-16, 2012: > >> >> http://camelone.com > >> >> >>>>>>>>>>> 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/ > >> >> >>>>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>>> -- > >> >> >>>>>>>>> Claus Ibsen > >> >> >>>>>>>>> ----------------- > >> >> >>>>>>>>> CamelOne 2012 Conference, May 15-16, 2012: > >> http://camelone.com > >> >> >>>>>>>>> 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/ > >> >> >>>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>> > >> >> >>>>>> > >> >> >>>>> > >> >> >>> > >> >> > >> > > >> > > >> > >> > >> Atos Worldline SA/NV - Chaussee de Haecht 1442 Haachtsesteenweg > >> - 1130 Brussels - Belgium > >> RPM-RPR Bruxelles-Brussel - TVA-BTW BE 0418.547.872 > >> Bankrekening-Compte Bancaire-Bank Account 310-0269424-44 > >> BIC BBRUBEBB - IBAN BE55 3100 2694 2444 > >> > >> "The information contained in this e-mail and any attachment thereto is > >> confidential and may contain information which is protected by > intellectual > >> property rights. > >> This information is intended for the exclusive use of the recipient(s) > >> named above. > >> This e-mail does not constitute any binding relationship or offer toward > >> any of the addressees. > >> If you are not one of the addressees , one of their employees or a proxy > >> holder entitled to hand over this message to the addressee(s), any use > of > >> the information contained herein (e.g. reproduction, divulgation, > >> communication or distribution,...) is prohibited. > >> If you have received this message in error, please notify the sender and > >> destroy it immediately after. > >> The integrity and security of this message cannot be guaranteed and it > >> may be subject to data corruption, interception and unauthorized > amendment, > >> for which we accept no liability." > >> > > > > >
