Camel CDI with non JTA transaction manager?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Camel CDI with non JTA transaction manager?

Gary Hodgson
Hi Antonin,

Thanks for the response. I'll revisit my previous attempts at integrating
standalone JTA - I believe I got a working example going, but had to put it
on hold during the testing.  If I get a sufficiently good example going
then I'll post a link here in case it's useful for others.

Cheers,
Gary

From: Antonin Stefanutti <>
To: "[hidden email]" <[hidden email]>
Cc:
Bcc:
Date: Thu, 18 Oct 2018 09:45:42 +0000
Subject: Re: Camel CDI with non JTA transaction manager?
Hi Gary,

Your understanding is correct. Transaction support in Camel CDI depends on
JTA.

That being said, it is possible to use it in a Java SE environment by
adding JTA API
and a transaction manager, as Narayana or Atomikos, in the classpath.

Then, you can produce Spring PlatformTransactionManager like:

@Produces
@Singleton
@Named("jtaTransactionManager")
PlatformTransactionManager createTransactionManager(TransactionManager
transactionManager, UserTransaction userTransaction) {
    JtaTransactionManager jtaTransactionManager = new
JtaTransactionManager();
    jtaTransactionManager.setUserTransaction(userTransaction);
    jtaTransactionManager.setTransactionManager(transactionManager);
    jtaTransactionManager.afterPropertiesSet();
    return jtaTransactionManager;
}

And the JMS component:

@Produces
@Named("jms-input")
@ApplicationScoped
Component produceInputJmsComponent(@ConfigProperty(name =
"jms.input.consumers") String inputQueueConcurrentConsumers) {
    CachingConnectionFactory cachingConnectionFactory = new
CachingConnectionFactory(connectionFactory);

cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(consumers));
    return JmsComponent.jmsComponent(cachingConnectionFactory);

}

void disposeInputJmsComponent(@Disposes @Named("jms-input") Component
component) {
    ((SingleConnectionFactory)
component.getConfiguration().getConnectionFactory()).destroy();
}

So that, you can write in your Camel routes:

from("jms-input:queue:{{jms.input.destination}}?transacted=true&concurrentConsumers={{jms.input.consumers}}&transactionManager=#jtaTransactionManager&cacheLevelName={{jms.input.consumers.cacheLevel}}")

I’ve already seen it implemented successfully.

Antonin

> On 18 Oct 2018, at 10:43, Gary Hodgson <> wrote:
>
> Hi,
>
> Is there a way to use JMSTransactionManager with cdi camel routes, i.e.
not
> JTA? It seems from the documentation and from googling that only JTA is
> supported, and if this is the case then that entails camel-cdi is only
> usable in JavaEE environments (when transactions are to be used at least).
>
> We're using camel routes with CDI in a JavaSE environment but would like
to
> utilise the Transactional Client EIP rather than relying on exception
> handlers.
>
> Any hints would be appreciated,
> Gary
Reply | Threaded
Open this post in threaded view
|

Re: Camel CDI with non JTA transaction manager?

astefanutti


> On 19 Oct 2018, at 12:33, Gary Hodgson <[hidden email]> wrote:
>
> Hi Antonin,
>
> Thanks for the response. I'll revisit my previous attempts at integrating standalone JTA - I believe I got a working example going, but had to put it on hold during the testing.  If I get a sufficiently good example going then I'll post a link here in case it's useful for others.

That’d be awesome. I think having an example for Camel CDI / JMS (using Spring PlatformTransactionManager) / JTA / Java SE would be very valuable.

> Cheers,
> Gary
>
> From: Antonin Stefanutti <>
> To: "[hidden email]" <[hidden email]>
> Cc:
> Bcc:
> Date: Thu, 18 Oct 2018 09:45:42 +0000
> Subject: Re: Camel CDI with non JTA transaction manager?
> Hi Gary,
>
> Your understanding is correct. Transaction support in Camel CDI depends on JTA.
>
> That being said, it is possible to use it in a Java SE environment by adding JTA API
> and a transaction manager, as Narayana or Atomikos, in the classpath.
>
> Then, you can produce Spring PlatformTransactionManager like:
>
> @Produces
> @Singleton
> @Named("jtaTransactionManager")
> PlatformTransactionManager createTransactionManager(TransactionManager transactionManager, UserTransaction userTransaction) {
>     JtaTransactionManager jtaTransactionManager = new JtaTransactionManager();
>     jtaTransactionManager.setUserTransaction(userTransaction);
>     jtaTransactionManager.setTransactionManager(transactionManager);
>     jtaTransactionManager.afterPropertiesSet();
>     return jtaTransactionManager;
> }
>
> And the JMS component:
>
> @Produces
> @Named("jms-input")
> @ApplicationScoped
> Component produceInputJmsComponent(@ConfigProperty(name = "jms.input.consumers") String inputQueueConcurrentConsumers) {
>     CachingConnectionFactory cachingConnectionFactory = new CachingConnectionFactory(connectionFactory);
>     cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(consumers));
>     return JmsComponent.jmsComponent(cachingConnectionFactory);
>
> }
>
> void disposeInputJmsComponent(@Disposes @Named("jms-input") Component component) {
>     ((SingleConnectionFactory) component.getConfiguration().getConnectionFactory()).destroy();
> }
>
> So that, you can write in your Camel routes:
>
> from("jms-input:queue:{{jms.input.destination}}?transacted=true&concurrentConsumers={{jms.input.consumers}}&transactionManager=#jtaTransactionManager&cacheLevelName={{jms.input.consumers.cacheLevel}}")
>
> I’ve already seen it implemented successfully.
>
> Antonin
>
> > On 18 Oct 2018, at 10:43, Gary Hodgson <> wrote:
> >
> > Hi,
> >
> > Is there a way to use JMSTransactionManager with cdi camel routes, i.e. not
> > JTA? It seems from the documentation and from googling that only JTA is
> > supported, and if this is the case then that entails camel-cdi is only
> > usable in JavaEE environments (when transactions are to be used at least).
> >
> > We're using camel routes with CDI in a JavaSE environment but would like to
> > utilise the Transactional Client EIP rather than relying on exception
> > handlers.
> >
> > Any hints would be appreciated,
> > Gary