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." > > >
