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