You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Daniel Pocock <da...@pocock.pro> on 2014/12/04 16:41:22 UTC
Camel distributed transactions/XA without full J2EE container?
The wiki explains the general concepts around transactions and
distributed transactions.
Running Camel as a standalone J2SE Spring application (using
org.apache.camel.spring.Main) is a popular choice for people who don't
want to use a container and I've worked on several projects where this
type of deployment was desired.
In this scenario, without a container, Camel transactions involving a
single JMS or JDBC provider work using the transaction capabilities of
the provider.
When a distributed transaction is required, Camel relies on Spring's
transaction support and Spring seems to need some standalone JTA
implementation. This is where it gets tricky.
I managed to get this working on one project using JOTM but it is
awkward (reasons below) and I'm just wondering if there is an example of
a solution that is simpler to implement.
The JOTM-based solution involved the following:
- add xbean-spring, JOTM and Carol JARs to classpath
- include JotmFactoryBean and JtaPersistenceUnitPostProcessor classes in
the project (I don't recall why this was necessary as it appears to
exist in Spring too)
- in the jndi.xml for xbean-spring, create the java:comp/UserTransaction
in JNDI using JotmFactoryBean:
<entry key="java:comp/UserTransaction">
<bean class="org.example.util.JotmFactoryBean" />
</entry>
and also create JNDI entries for each DataSource using the bean class
com.mchange.v2.c3p0.ComboPooledDataSource:
<entry key="java:comp/env/jdbc/testDS">
<bean
class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass"
value="com.mysql.jdbc.Driver" />
<property name="jdbcUrl"
value="jdbc:mysql://localhost:3306/test1" />
<property name="user" value="test" />
<property name="password" value="123" />
<property name="maxIdleTime" value="1800" />
</bean>
</entry>
- in the camelContext.xml, create spring beans using the above objects
from JNDI:
<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
<property name="environment">
<props>
<prop
key="java.naming.factory.initial">org.apache.xbean.spring.jndi.SpringInitialContextFactory</prop>
<prop
key="java.naming.provider.url">classpath:jndi.xml</prop>
</props>
</property>
</bean>
<bean id="testDataSource"
class="org.springframework.jndi.JndiObjectFactoryBean" autowire="no">
<property name="jndiName" value="java:comp/env/jdbc/testDS" />
<property name="jndiTemplate" ref="jndiTemplate" />
</bean>
<bean id="myPersistenceProvider"
class="org.hibernate.ejb.HibernatePersistence" />
<bean id="pu-test"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceXmlLocation"
value="classpath:META-INF/persistence-test.xml" />
<property name="persistenceUnitName" value="pu-test" />
<property name="dataSource" ref="testDataSource" />
<property name="persistenceProvider" ref="myPersistenceProvider" />
<property name="persistenceUnitPostProcessors">
<bean class="org.example.util.JtaPersistenceUnitPostProcessor">
<property name="jtaDataSource" ref="testDataSource" />
</bean>
</property>
<property name="jpaVendorAdapter">
<bean
class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="showSql" value="true" />
<property name="database" value="MYSQL" />
</bean>
</property>
<property name="jpaProperties">
<props>
<prop
key="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</prop>
<prop
key="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JOTMTransactionManagerLookup</prop>
<prop
key="jta.UserTransaction">java:comp/UserTransaction</prop>
</props>
</property>
</bean>
<bean id="jotmTransactionManager"
class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="userTransaction">
<jee:jndi-lookup jndi-name="java:comp/UserTransaction"/>
</property>
</bean>
<bean id="PROPAGATION_REQUIRED"
class="org.apache.camel.spring.spi.SpringTransactionPolicy">
<property name="transactionManager" ref="jotmTransactionManager" />
<property name="propagationBehaviorName"
value="PROPAGATION_REQUIRED" />
</bean>
<bean
class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"
/>
<tx:annotation-driven transaction-manager="jotmTransactionManager" />
<bean id="jpa" class="org.apache.camel.component.jpa.JpaComponent">
<property name="entityManagerFactory" ref="pu-test" />
<property name="transactionManager" ref="jotmTransactionManager" />
</bean>
- and also add ActiveMQ with JTA support:
<bean id="activemq"
class="org.apache.activemq.camel.component.ActiveMQComponent">
<property name="brokerURL" value="tcp://localhost:61616" />
<property name="transactionManager" ref="jotmTransactionManager" />
</bean>
The good news is, this seems to work without any container.
The bad news is, it is not trivial to create the runtime classpath.
- I have a working, hand-crafted runtime classpath based on the specific
project concerned.
- when I tried to put new Camel JARs in the classpath (not changing
anything else or the order of the JARS), JOTM would fail to initialize,
exceptions from Carol
- when I tried to build the project with Maven (it was originally built
with Ant), I can run it successfully with:
mvn exec:java -Dexec.mainClass=org.apache.camel.spring.Main
but if I try to run the JVM from a script using the classpath
generated by
mvn dependency:build-classpath
then JOTM fails to initialize, once again, giving exceptions from
the Carol JAR
My overall impression is that this is quite tedious to get it right and
can break easily when more dependencies are added, especially if Maven
is helping. Does anybody have a suggestion or examples, possibly using
another transaction manager?
Re: Camel distributed transactions/XA without full J2EE container?
Posted by alexey-s <al...@mail.ru>.
Hi
Please read my opinion on account of Aries Transaction.
See
http://camel.465427.n5.nabble.com/OSGI-Apache-Aries-Transaction-td5760310.html
https://issues.apache.org/jira/browse/ARIES-1279
Another author: https://issues.jboss.org/browse/ENTESB-2244
On the topic of the question. In ARIES-1279 given test. In the test rises
TransactionManager without infrastructures JEE/OSGI.
Aleksey
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-distributed-transactions-XA-without-full-J2EE-container-tp5760152p5760360.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel distributed transactions/XA without full J2EE container?
Posted by Charlie Mordant <cm...@gmail.com>.
Hi Claus,
Aries JTA is the name of the JTA implementation given with Karaf.
Regards,
Charlie
2014-12-05 13:56 GMT+01:00 Jakub Korab <ja...@gmail.com>:
> I can't speak for the Camel In Action guys, but we picked Atomikos
> fundamentally because the license for TransactionEssentials is Apache
> 2.0, all of the JARs are available in Maven global and the documentation
> is outstanding. The guys were also really helpful in working through
> issues.
>
> You can find the dependencies via:
> http://mvnrepository.com/search?q=Atomikos+TransactionEssentials
>
> Example code for XA transactions (with a POM that includes all the
> Atomikos jars) is available in:
>
> https://github.com/CamelCookbook/camel-cookbook-examples/tree/master/camel-cookbook-transactions
>
> I would have liked to stay Apache all the way down, but the lack of
> documentation was a problem. Having said that, I'm sure if you ask on
> the Geronimo mailing list about using their transaction manager
> out-of-container someone will help you out.
>
> Jakub Korab
> Author - Apache Camel Developer's Cookbook
>
> On 05/12/14 10:12, Daniel Pocock wrote:
> > On 04/12/14 16:48, Claus Ibsen wrote:
> >> Hi
> >>
> >> Both the Camel books - Camel in Action and the cookbook has JTA
> >> examples using atomikos as the TX manager. And the examples are
> >> standalone and can run from unit tests etc.
> > I'm a bit wary of examples using Atomikos in free software projects,
> > they say their code is free but I could never find the source code
> > (either a tarball or repository) anywhere.
> >
> > Their community page doesn't appear to give any starting point for
> > developers to clone the project:
> >
> > http://www.atomikos.com/Main/AtomikosCommunity
> >
> >
> >> And there is also the TX manager from Apache geronimo project - not
> >> remember its name. But I think its the one that Apache Karaf comes
> >> with.
> >>
> > That is the one that Maven tries to pull in (even if JOTM is requested)
> >
> > Is there any reason why Atomikos was chosen over geronimo in the books?
> >
> >
> >
>
>
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: Camel distributed transactions/XA without full J2EE container?
Posted by Daniel Pocock <da...@pocock.pro>.
On 08/12/14 21:51, GuyPardon wrote:
> Hi,
>
> I am from Atomikos. I can confirm that our software is open source and
> apache-licensed (and as far as I am concerned always will be - we never
> regretted moving towards open source so far). You can use it any way you
> like, as long as you like, rebrand it or whatever - but if you want
> professional bug fixes from us then you pay for a subscription. I don't
> think this model is unfair, it is what RedHat is doing too AFAIK.
Guy, thanks for taking the time to comment on this.
There is nothing wrong with getting paid to work on free software - most
free/open source software has been produced by people who were paid in
one way or another. I don't think there was anything that has been said
against this. I sincerely hope everybody producing the free software I
use myself has been fairly paid for their contribution to it.
The only question is the availability of the source code, I simply
couldn't find a download link or Github page from Atomikos.com. Ever
since businesses started warming up the immense benefits of free
software/open source software, virtually everybody has tried to get on
the bandwagon, e.g. sites like this started popping up:
http://www.microsoft.com/opensource/
For those projects that are truly part of this eco-system - and Atomikos
obviously seems like a more natural fit than Microsoft - don't you think
it is important to distinguish genuine free software projects from such
gimmicks by highlighting the availability of the code (and usually the
repository) with minimum effort to download it and participate?
> Actually we've been wondering quite a few times already whether to move to
> GitHub but haven't yet mainly for one big reason: we don't know any
> professional open source project that is making money in a sustainable way
> on GitHub (besides maybe GitHub itself). RedHat isn't (or is it?). I know
> there is Hazelcast (with all respect due), but they operate on VC money and
> are only doing this since very recently so I am not sure how sustainable
> that is going to be for them.
Is there evidence that using a public repository has a correlation with
profitability or the lack of it? Personally, I don't think a business
that is making or losing money today is suddenly going to change their
position overnight just by going onto Github or taking their code back
in-house if there are more fundamental issues with their business model.
For most users of JTA code the primary concern is usually quality.
Engaging more developer participation through Github may improve quality
and that can only be a good thing. Every day I find some quality issue
in a project, when it is on Github I usually send the fix and sometimes
even a unit test as a pull request. I can develop such fixes faster and
work more productively when I can see the history of the relevant files
in a live repository, e.g. to see if other developers are working on
them within the last week or if they haven't touched the relevant file
for 6 months.
Regards,
Daniel
Re: Camel distributed transactions/XA without full J2EE container?
Posted by Daniel Pocock <da...@pocock.pro>.
On 09/12/14 11:58, alexey-s wrote:
> You are not faced with the problem of access to GitHUB. Recently, in Russia,
> this resource was not available for several days.
<snip>
> It is better to have a few mirrors. How to git on apache.org and GitHub.
Technically, that is exactly the type of problem Git is meant to solve.
Git is a distributed version control system so it is far less vulnerable
to such problems (whether they be technical, political, economic, such
as firms going out of business or being taken over) when compared to SVN
or other client-server solutions.
Re: Camel distributed transactions/XA without full J2EE container?
Posted by alexey-s <al...@mail.ru>.
You are not faced with the problem of access to GitHUB. Recently, in Russia,
this resource was not available for several days.
This multi-million developers have lost access to their projects.
Well, that someone wrote for GitHUB system blocking parts of sections for
whole regions (countries).
God forbid, be your organization in the role of the victim of the conflict
of laws and the contents of the site in your country.
It is better to have a few mirrors. How to git on apache.org and GitHub.
Aleksey
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-distributed-transactions-XA-without-full-J2EE-container-tp5760152p5760379.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel distributed transactions/XA without full J2EE container?
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Guy,
I do not fully understand what your issue with github (or similar) is.
It should not be the cost part. I am not sure if github would cost
anything for organizational use if your repositories are open.
I work for Talend and we host all our development on github. It has some
advantages for us:
1. We do not need to manage the repository on a server and software
level (This probably saves us more money than we pay to github)
2. We get some visibility for the open source parts of our software.
(see https://github.com/Talend)
3. We can still have some private repositories.
Unfortunately we do not really exploit the fact that we host most of our
developments in the open from a marketing perspective. Still I think it
is no disadvantage.
To be fair we are venture capital funded but I do not see how this
relates to where and how open you host your code. After all you already
are apache licensed. So your code is visible anyway.
Christian
On 08.12.2014 21:51, GuyPardon wrote:
> Hi,
>
> I am from Atomikos. I can confirm that our software is open source and
> apache-licensed (and as far as I am concerned always will be - we never
> regretted moving towards open source so far). You can use it any way you
> like, as long as you like, rebrand it or whatever - but if you want
> professional bug fixes from us then you pay for a subscription. I don't
> think this model is unfair, it is what RedHat is doing too AFAIK.
>
> Actually we've been wondering quite a few times already whether to move to
> GitHub but haven't yet mainly for one big reason: we don't know any
> professional open source project that is making money in a sustainable way
> on GitHub (besides maybe GitHub itself). RedHat isn't (or is it?). I know
> there is Hazelcast (with all respect due), but they operate on VC money and
> are only doing this since very recently so I am not sure how sustainable
> that is going to be for them.
>
> In short: we never had VC money and had to earn every euro we ever spent.
> That's been a major factor in every decision we ever made so far. That being
> said, we're always eager to learn and adapt so please feel free to prove us
> wrong...
>
> Thanks
> Guy
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-distributed-transactions-XA-without-full-J2EE-container-tp5760152p5760337.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Camel distributed transactions/XA without full J2EE container?
Posted by GuyPardon <gu...@atomikos.com>.
Hi,
I am from Atomikos. I can confirm that our software is open source and
apache-licensed (and as far as I am concerned always will be - we never
regretted moving towards open source so far). You can use it any way you
like, as long as you like, rebrand it or whatever - but if you want
professional bug fixes from us then you pay for a subscription. I don't
think this model is unfair, it is what RedHat is doing too AFAIK.
Actually we've been wondering quite a few times already whether to move to
GitHub but haven't yet mainly for one big reason: we don't know any
professional open source project that is making money in a sustainable way
on GitHub (besides maybe GitHub itself). RedHat isn't (or is it?). I know
there is Hazelcast (with all respect due), but they operate on VC money and
are only doing this since very recently so I am not sure how sustainable
that is going to be for them.
In short: we never had VC money and had to earn every euro we ever spent.
That's been a major factor in every decision we ever made so far. That being
said, we're always eager to learn and adapt so please feel free to prove us
wrong...
Thanks
Guy
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-distributed-transactions-XA-without-full-J2EE-container-tp5760152p5760337.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel distributed transactions/XA without full J2EE container?
Posted by Daniel Pocock <da...@pocock.pro>.
On 05/12/14 13:56, Jakub Korab wrote:
> I can't speak for the Camel In Action guys, but we picked Atomikos
> fundamentally because the license for TransactionEssentials is Apache
> 2.0, all of the JARs are available in Maven global and the documentation
> is outstanding. The guys were also really helpful in working through issues.
>
> You can find the dependencies via:
> http://mvnrepository.com/search?q=Atomikos+TransactionEssentials
>
> Example code for XA transactions (with a POM that includes all the
> Atomikos jars) is available in:
> https://github.com/CamelCookbook/camel-cookbook-examples/tree/master/camel-cookbook-transactions
>
> I would have liked to stay Apache all the way down, but the lack of
> documentation was a problem. Having said that, I'm sure if you ask on
> the Geronimo mailing list about using their transaction manager
> out-of-container someone will help you out.
Ok, thanks for this feedback - so it was more about lack of
documentation than any specific flaw in the Geronimo/Aries JTA solutions
I didn't intend to be disparaging of Atomikos, rather, I just think it
is important to highlight the availability of open, community based
solutions as they are closer to the way other Apache projects like Camel
itself are managed. Those projects that have been brave enough to put
their repository out there, warts and all, for anybody to see in detail
and check the history of a particular source file for example and see
who committed something that caused a regression. The best way to
encourage teams like Atomikos to get their code on Github (or another
VCS) is to highlight those projects that have already made that step.
Availability in the Maven repository definitely does not indicate that
software is free. Some of the stuff in there is quite scary. When
somebody submits something there, it is not compiled independently from
source so there is no certainty that anybody else can rebuild the some
JAR with a patch if they really need to.
Re: Camel distributed transactions/XA without full J2EE container?
Posted by Jakub Korab <ja...@gmail.com>.
I can't speak for the Camel In Action guys, but we picked Atomikos
fundamentally because the license for TransactionEssentials is Apache
2.0, all of the JARs are available in Maven global and the documentation
is outstanding. The guys were also really helpful in working through issues.
You can find the dependencies via:
http://mvnrepository.com/search?q=Atomikos+TransactionEssentials
Example code for XA transactions (with a POM that includes all the
Atomikos jars) is available in:
https://github.com/CamelCookbook/camel-cookbook-examples/tree/master/camel-cookbook-transactions
I would have liked to stay Apache all the way down, but the lack of
documentation was a problem. Having said that, I'm sure if you ask on
the Geronimo mailing list about using their transaction manager
out-of-container someone will help you out.
Jakub Korab
Author - Apache Camel Developer's Cookbook
On 05/12/14 10:12, Daniel Pocock wrote:
> On 04/12/14 16:48, Claus Ibsen wrote:
>> Hi
>>
>> Both the Camel books - Camel in Action and the cookbook has JTA
>> examples using atomikos as the TX manager. And the examples are
>> standalone and can run from unit tests etc.
> I'm a bit wary of examples using Atomikos in free software projects,
> they say their code is free but I could never find the source code
> (either a tarball or repository) anywhere.
>
> Their community page doesn't appear to give any starting point for
> developers to clone the project:
>
> http://www.atomikos.com/Main/AtomikosCommunity
>
>
>> And there is also the TX manager from Apache geronimo project - not
>> remember its name. But I think its the one that Apache Karaf comes
>> with.
>>
> That is the one that Maven tries to pull in (even if JOTM is requested)
>
> Is there any reason why Atomikos was chosen over geronimo in the books?
>
>
>
Re: Camel distributed transactions/XA without full J2EE container?
Posted by Daniel Pocock <da...@pocock.pro>.
On 04/12/14 16:48, Claus Ibsen wrote:
> Hi
>
> Both the Camel books - Camel in Action and the cookbook has JTA
> examples using atomikos as the TX manager. And the examples are
> standalone and can run from unit tests etc.
I'm a bit wary of examples using Atomikos in free software projects,
they say their code is free but I could never find the source code
(either a tarball or repository) anywhere.
Their community page doesn't appear to give any starting point for
developers to clone the project:
http://www.atomikos.com/Main/AtomikosCommunity
> And there is also the TX manager from Apache geronimo project - not
> remember its name. But I think its the one that Apache Karaf comes
> with.
>
That is the one that Maven tries to pull in (even if JOTM is requested)
Is there any reason why Atomikos was chosen over geronimo in the books?
Re: Camel distributed transactions/XA without full J2EE container?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Both the Camel books - Camel in Action and the cookbook has JTA
examples using atomikos as the TX manager. And the examples are
standalone and can run from unit tests etc.
And there is also the TX manager from Apache geronimo project - not
remember its name. But I think its the one that Apache Karaf comes
with.
On Thu, Dec 4, 2014 at 4:41 PM, Daniel Pocock <da...@pocock.pro> wrote:
>
>
> The wiki explains the general concepts around transactions and
> distributed transactions.
>
> Running Camel as a standalone J2SE Spring application (using
> org.apache.camel.spring.Main) is a popular choice for people who don't
> want to use a container and I've worked on several projects where this
> type of deployment was desired.
>
> In this scenario, without a container, Camel transactions involving a
> single JMS or JDBC provider work using the transaction capabilities of
> the provider.
>
> When a distributed transaction is required, Camel relies on Spring's
> transaction support and Spring seems to need some standalone JTA
> implementation. This is where it gets tricky.
>
> I managed to get this working on one project using JOTM but it is
> awkward (reasons below) and I'm just wondering if there is an example of
> a solution that is simpler to implement.
>
> The JOTM-based solution involved the following:
> - add xbean-spring, JOTM and Carol JARs to classpath
> - include JotmFactoryBean and JtaPersistenceUnitPostProcessor classes in
> the project (I don't recall why this was necessary as it appears to
> exist in Spring too)
> - in the jndi.xml for xbean-spring, create the java:comp/UserTransaction
> in JNDI using JotmFactoryBean:
>
> <entry key="java:comp/UserTransaction">
> <bean class="org.example.util.JotmFactoryBean" />
> </entry>
>
> and also create JNDI entries for each DataSource using the bean class
> com.mchange.v2.c3p0.ComboPooledDataSource:
>
> <entry key="java:comp/env/jdbc/testDS">
> <bean
> class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
> <property name="driverClass"
> value="com.mysql.jdbc.Driver" />
> <property name="jdbcUrl"
> value="jdbc:mysql://localhost:3306/test1" />
> <property name="user" value="test" />
> <property name="password" value="123" />
> <property name="maxIdleTime" value="1800" />
> </bean>
> </entry>
>
> - in the camelContext.xml, create spring beans using the above objects
> from JNDI:
>
> <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
> <property name="environment">
> <props>
> <prop
> key="java.naming.factory.initial">org.apache.xbean.spring.jndi.SpringInitialContextFactory</prop>
> <prop
> key="java.naming.provider.url">classpath:jndi.xml</prop>
> </props>
> </property>
> </bean>
>
> <bean id="testDataSource"
> class="org.springframework.jndi.JndiObjectFactoryBean" autowire="no">
> <property name="jndiName" value="java:comp/env/jdbc/testDS" />
> <property name="jndiTemplate" ref="jndiTemplate" />
> </bean>
>
> <bean id="myPersistenceProvider"
> class="org.hibernate.ejb.HibernatePersistence" />
>
> <bean id="pu-test"
> class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
> <property name="persistenceXmlLocation"
> value="classpath:META-INF/persistence-test.xml" />
> <property name="persistenceUnitName" value="pu-test" />
> <property name="dataSource" ref="testDataSource" />
> <property name="persistenceProvider" ref="myPersistenceProvider" />
> <property name="persistenceUnitPostProcessors">
> <bean class="org.example.util.JtaPersistenceUnitPostProcessor">
> <property name="jtaDataSource" ref="testDataSource" />
> </bean>
> </property>
> <property name="jpaVendorAdapter">
> <bean
> class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
> <property name="showSql" value="true" />
> <property name="database" value="MYSQL" />
> </bean>
> </property>
> <property name="jpaProperties">
> <props>
> <prop
> key="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</prop>
> <prop
> key="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JOTMTransactionManagerLookup</prop>
> <prop
> key="jta.UserTransaction">java:comp/UserTransaction</prop>
> </props>
> </property>
> </bean>
>
> <bean id="jotmTransactionManager"
> class="org.springframework.transaction.jta.JtaTransactionManager">
> <property name="userTransaction">
> <jee:jndi-lookup jndi-name="java:comp/UserTransaction"/>
> </property>
> </bean>
>
> <bean id="PROPAGATION_REQUIRED"
> class="org.apache.camel.spring.spi.SpringTransactionPolicy">
> <property name="transactionManager" ref="jotmTransactionManager" />
> <property name="propagationBehaviorName"
> value="PROPAGATION_REQUIRED" />
> </bean>
>
> <bean
> class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"
> />
>
> <tx:annotation-driven transaction-manager="jotmTransactionManager" />
>
> <bean id="jpa" class="org.apache.camel.component.jpa.JpaComponent">
> <property name="entityManagerFactory" ref="pu-test" />
> <property name="transactionManager" ref="jotmTransactionManager" />
> </bean>
>
>
> - and also add ActiveMQ with JTA support:
>
> <bean id="activemq"
> class="org.apache.activemq.camel.component.ActiveMQComponent">
> <property name="brokerURL" value="tcp://localhost:61616" />
> <property name="transactionManager" ref="jotmTransactionManager" />
> </bean>
>
>
> The good news is, this seems to work without any container.
>
> The bad news is, it is not trivial to create the runtime classpath.
> - I have a working, hand-crafted runtime classpath based on the specific
> project concerned.
> - when I tried to put new Camel JARs in the classpath (not changing
> anything else or the order of the JARS), JOTM would fail to initialize,
> exceptions from Carol
> - when I tried to build the project with Maven (it was originally built
> with Ant), I can run it successfully with:
>
> mvn exec:java -Dexec.mainClass=org.apache.camel.spring.Main
>
> but if I try to run the JVM from a script using the classpath
> generated by
>
> mvn dependency:build-classpath
>
> then JOTM fails to initialize, once again, giving exceptions from
> the Carol JAR
>
> My overall impression is that this is quite tedious to get it right and
> can break easily when more dependencies are added, especially if Maven
> is helping. Does anybody have a suggestion or examples, possibly using
> another transaction manager?
>
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/