Re: [HEADS UP] Camel K is here!

[Alex Dettinger]

Whaoo, I've had a look at introducing-camel-k
 from Nicolas
and that's awesome.
Well done guys !

On Thu, Oct 18, 2018 at 4:25 AM Willem Jiang  wrote:

> Yeah,  it's great to see we can use Camel more easily with K8S.
> It's awesome that camel-k can be a part of Camel 3 :)
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Oct 17, 2018 at 6:24 AM Nicola Ferraro 
> wrote:
> >
> > Hi folks,
> > after some months of brainstorming with the community and a bit more than
> > one month of development, our Camel K project has reached a good level of
> > stability and I've published the first blog post about it yesterday.
> >
> > For those of you who haven't heard of Camel K, it's now a subproject of
> > Apache Camel (https://github.com/apache/camel-k) with the target of
> > building a lightweight runtime for running integration code directly on
> > cloud platforms like Kubernetes and Openshift. It was inspired by
> > "serverless" principles and it will also target Knative shortly.
> >
> > With the exception of the runtime code, that remains the good old Camel
> > Java framework with 200+ components and full of EIPs, most of the
> > "operator" code in Camel K is written in Go. But the new language has not
> > stopped many adventurer Camel developers that have actively contributed
> to
> > the project during last month. We still have a long way in front of us,
> > let's continue to make Camel great!
> >
> > So, please.. check the project out! Spread it to the world!
> > And provide your feedback, so we can make it always better. We love any
> > kind of contribution!
> >
> > Links follow..
> >
> > Announcement: https://twitter.com/ni_ferraro/status/1051872786946363392
> > Article: https://www.nicolaferraro.me/2018/10/15/introducing-camel-k/
> > Home: https://github.com/apache/camel-k
> >
> > Nicola
>

Re: Camel CDI with non JTA transaction manager?

[Antonin Stefanutti]

> On 19 Oct 2018, at 12:33, Gary Hodgson  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: "users@camel.apache.org" 
> Cc: 
> Bcc: 
> Date: Thu, 18 Oct 2018 09:45:42 +
> 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

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: "users@camel.apache.org" 
Cc:
Bcc:
Date: Thu, 18 Oct 2018 09:45:42 +
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

Re: concurrentConsumers create duplicated messages and fail

[Damien Nicolas]

Ok.. I forgot to add the InOut pattern on my camel consuming queue.

Le ven. 19 oct. 2018 à 09:18, Damien Nicolas  a
écrit :

> up
>
> Le mar. 16 oct. 2018 à 16:40, Damien Nicolas  a
> écrit :
>
>> Hello,
>>
>> I have a Springboot war with Camel routes deployed on a JBoss EAP 7.1
>> server. The routes are generated dynamically and some of them have 
>> *concurrentConsumers
>> > 1* because a route can have several times the same processor;
>>
>> example (here a schematically representation of a route):
>> cxf -> jmsx -> jms1 -> p1 -> jms2 -> p2 -> jms1 -> p1 -> jms3 -> p3...
>>
>> where jms1 will have* concurrentConsumers=2 *cause it use two times p1.
>> This is working wonderfully.
>>
>> But, for architectural purpose, I had to split the application in 2. Each
>> half of the application is on a different JBoss server, schematized here:
>>
>> *JBoss1 |  JBoss2*
>> *cxf -> |   jmsx -> jms1 -> p1 -> jms2 -> p2 -> jms1 -> p1 -> jms3 ->
>> p3... *
>>
>>  "jmsx" is a remote queue which is the link between the two servers, and
>> is used to "inject" messages into the Camel business. The messages are
>> correctly consumed by Camel, but when they arrived on a part where *
>> concurrentConsumer=n*, the messages are duplicated n times and make the
>> workflow fails.
>>
>> The messages are created on JBoss1 with JMS:
>>
>> Session s = connectionFactory.createConnection("test3", 
>> "test3").createSession();
>> ObjectMessage m = s.createObjectMessage();
>> m.setObject(object);
>> m.setStringProperty("Accept", "application/json");
>> m.setStringProperty("Content_Type", "application/json");
>> m.setStringProperty("type", "chip");
>> m.setStringProperty("hasCertificate", "true");
>> m.setStringProperty("priority", "NORMAL");
>> m.setStringProperty("context", "xxx");
>>
>> try (JMSContext context = 
>> connectionFactory.createContext(userName, password)) {
>> context.createProducer().send(destination, m);
>> ...
>>
>>
>> Is the problem comes about the fact there is less header properties
>> generated when I create manually the headers?? or something else???
>> Here is the difference between the header properties of the first version
>> of the project and the second one 
>>
>>
>> --
>> Damien NICOLAS
>>
>
>
> --
> Damien NICOLAS
>


-- 
Damien NICOLAS

Re: concurrentConsumers create duplicated messages and fail

[Damien Nicolas]

up

Le mar. 16 oct. 2018 à 16:40, Damien Nicolas  a
écrit :

> Hello,
>
> I have a Springboot war with Camel routes deployed on a JBoss EAP 7.1
> server. The routes are generated dynamically and some of them have 
> *concurrentConsumers
> > 1* because a route can have several times the same processor;
>
> example (here a schematically representation of a route):
> cxf -> jmsx -> jms1 -> p1 -> jms2 -> p2 -> jms1 -> p1 -> jms3 -> p3...
>
> where jms1 will have* concurrentConsumers=2 *cause it use two times p1.
> This is working wonderfully.
>
> But, for architectural purpose, I had to split the application in 2. Each
> half of the application is on a different JBoss server, schematized here:
>
> *JBoss1 |  JBoss2*
> *cxf -> |   jmsx -> jms1 -> p1 -> jms2 -> p2 -> jms1 -> p1 -> jms3 ->
> p3... *
>
>  "jmsx" is a remote queue which is the link between the two servers, and
> is used to "inject" messages into the Camel business. The messages are
> correctly consumed by Camel, but when they arrived on a part where *
> concurrentConsumer=n*, the messages are duplicated n times and make the
> workflow fails.
>
> The messages are created on JBoss1 with JMS:
>
> Session s = connectionFactory.createConnection("test3", 
> "test3").createSession();
> ObjectMessage m = s.createObjectMessage();
> m.setObject(object);
> m.setStringProperty("Accept", "application/json");
> m.setStringProperty("Content_Type", "application/json");
> m.setStringProperty("type", "chip");
> m.setStringProperty("hasCertificate", "true");
> m.setStringProperty("priority", "NORMAL");
> m.setStringProperty("context", "xxx");
>
> try (JMSContext context = 
> connectionFactory.createContext(userName, password)) {
> context.createProducer().send(destination, m);
> ...
>
>
> Is the problem comes about the fact there is less header properties
> generated when I create manually the headers?? or something else???
> Here is the difference between the header properties of the first version
> of the project and the second one 
>
>
> --
> Damien NICOLAS
>


-- 
Damien NICOLAS