Thanks Christian, I will take a look. In the real system we are definitely using more than just a single JMS resource as part of the transaction. I was just trying to show the problem with a simple test case.
Thanks, Chris On Mon, Apr 23, 2012 at 12:42 AM, Christian Müller < christian.muel...@gmail.com> wrote: > At the weekend I found some minutes to work on it. I created a few unit > tests for local JMS and JDBC transactions and for global JMS and JDBC XA > transactions. At present, you can find the samples at [1] but I plan to > move it also into the regular Camel test base for regression tests or into > a new XA transaction example project. > > I tested the XA transactions with Atomikos, Aries, JOTM and Bitronix. I got > they all working. I hope it will help to solve your issue. If not, please > ping me again... ;-) > > And by the way, because you only have one resource (JMS), you should > consider to only use a local JMS transaction which is much more faster than > the XA transactions (because of 2PC). > > [1] https://github.com/muellerc/camel-in-transaction/ > > Best, > Christian > > On Fri, Apr 20, 2012 at 5:59 AM, Chris Geer <ch...@cxtsoftware.com> wrote: > > > Arnaud, > > > > There are two approaches I've used. The first approach is to start with a > > SMX deployment and tweak it. The way I've done that is once I've unpacked > > the deployment I'll modify the various feature/config files and update > them > > to use the version I want. For example to make use of Camel 2.9.2 I would > > modify the servicemix feature to change the Camel version and update the > > org.apache.karaf.features.cfg file to point to the correct feature file > for > > Camel. You can use the same approach to update to other items. > > > > The second approach, and the one I use now, is to build a custom > > deployment. I did this by taking the apache-servicemix assembly project, > > making my own copy, and changing the required properties to use the > > versions you want. This will actually rebuild the servicemix feature > file, > > and org.apache.karaf.features.cfg file to use the correct versions. > > > > Hmmm...sounds like a good blog topic. Maybe someone has already written > > about it. > > > > Chris > > > > On Thu, Apr 19, 2012 at 5:36 AM, 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." > > > > > >
