camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <christian.muel...@gmail.com>
Subject Re: OSGI Transaction Propagation to Camel Route
Date Thu, 19 Apr 2012 19:09:25 GMT
I mean ActiveMq 5.6-SNAPSHOT...

Best,
Christian

On Thu, Apr 19, 2012 at 9:08 PM, Christian Müller <
christian.mueller@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.deprez@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:chris@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 <chris@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&amp;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 <raul@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 <raul@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 <chris@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 <
>> raul@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 <chris@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 <
>> raul@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.
>> >> >>>>> raul@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 <chris@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 <
>> >> raul@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.
>> >> >>>>>>> raul@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 <chris@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.ibsen@gmail.com>
>> >> >>>>>>> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>> On Thu, Apr 5, 2012 at 5:57 PM, Chris Geer <
>> >> chris@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.ibsen@gmail.com
>> >> >>>>>>>
>> >> >>>>>>>>> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> On Thu, Apr 5, 2012 at 4:59 PM, Chris Geer <
>> >> >>>>> chris@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.mueller@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 <
>> >> >>>>>>> chris@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: cibsen@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: cibsen@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."
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message