Re: Waiting for dependencies
You need to install camel-netty4-http
On Tue, May 11, 2021 at 8:30 AM Mike Oliver
wrote:
>
> I have the following camel context.
>
> http://camel.apache.org/schema/blueprint";>
>
> uri="restlet:{{server.protocol}}:{{server.host}}:{{server.port}}{{server.path}}?restletMethod=POST">
> Receives Current Grade from Camu
>
>
> The request raw from bpms
>
>
> {{api.key}}
>
> uri="netty4-http:{{client.protocol}}:{{client.host}}:{{client.port}}{{client.path}}"/>
>
>
>
> it builds fine with mvn clean install
>
> And then deploys with no errors to karaf
>
> However the camel context doesn't show in the Karaf console and in the OSGI
> bundles list it shows active but in the logs it shows...
>
> Unable to start container for blueprint bundle CamuGetGrade2/1.0.0.SNAPSHOT
> due to unresolved dependencies
> [(&(component=netty4-http)(objectClass=org.apache.camel.spi.ComponentResolver))]
>
> I tried features install camel-http and camel-netty4 with no impact.
>
> What can I try next.
>
> I chose netty4 because I found that reslet doesn't allow more than one
> bundle to have the same port for the reslet component and I have several
> routes that access the same external service.
>
>
>
>
> *Mike Oliver** Founder**, Open 4 Business Online*
> Tel: +1(951)260-0793 | Mobile:**NEW* 639479927462
> US Toll free: 1-800-985-4766 **NEW*
> http://www.o4bo.com
> Mas marunong akong umunawa ng salitang tagalog kaysa magkapagsalita nito
> [image: Facebook]
> [image:
> Twitter] [image: LinkedIn]
> [image: AngelList]
> [image: YouTube]
> [image: Google
> Plus Page]
> Contact me: [image: Google Talk] mikeolive...@open4businessonline.com [image:
> Skype] MikeOliverAZ
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Waiting for dependencies
Ok thanks will try that
On Tue, May 11, 2021, 3:07 PM Claus Ibsen wrote:
> You need to install camel-netty4-http
>
> On Tue, May 11, 2021 at 8:30 AM Mike Oliver
> wrote:
> >
> > I have the following camel context.
> >
> > http://camel.apache.org/schema/blueprint";>
> >
> > >
> uri="restlet:{{server.protocol}}:{{server.host}}:{{server.port}}{{server.path}}?restletMethod=POST">
> > Receives Current Grade from
> Camu
> >
> >
> > The request raw from bpms
> >
> >
> > {{api.key}}
> >
> > >
> uri="netty4-http:{{client.protocol}}:{{client.host}}:{{client.port}}{{client.path}}"/>
> >
> >
> >
> > it builds fine with mvn clean install
> >
> > And then deploys with no errors to karaf
> >
> > However the camel context doesn't show in the Karaf console and in the
> OSGI
> > bundles list it shows active but in the logs it shows...
> >
> > Unable to start container for blueprint bundle
> CamuGetGrade2/1.0.0.SNAPSHOT
> > due to unresolved dependencies
> >
> [(&(component=netty4-http)(objectClass=org.apache.camel.spi.ComponentResolver))]
> >
> > I tried features install camel-http and camel-netty4 with no impact.
> >
> > What can I try next.
> >
> > I chose netty4 because I found that reslet doesn't allow more than one
> > bundle to have the same port for the reslet component and I have several
> > routes that access the same external service.
> >
> >
> >
> >
> > *Mike Oliver** Founder**, Open 4 Business Online*
> > Tel: +1(951)260-0793 | Mobile:**NEW* 639479927462
> > US Toll free: 1-800-985-4766 **NEW*
> > http://www.o4bo.com
> > Mas marunong akong umunawa ng salitang tagalog kaysa magkapagsalita nito
> > [image: Facebook]
> >
> [image:
> > Twitter] [image: LinkedIn]
> > [image: AngelList]
> > [image: YouTube]
> > [image: Google
> > Plus Page]
> > Contact me: [image: Google Talk] mikeolive...@open4businessonline.com
> [image:
> > Skype] MikeOliverAZ
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
[camel-rabbitmq] - InOut pattern and temporary queues
Hi everyone, I'm developing an application that relies mostly on Camel (3.9.0) and its dedicated RabbitMQ / REST components. My routes are specified in XML (with Spring beans). Here's a simple route : The percolate_queue defined in another XML contains a single Camel processor, which returns a basic JSON. When I'm calling the REST endpoint : * A message is sent to percolate_queue without issues * The Camel processor is invoked, and returns its value (which I get as a response for my REST call) However, I noticed a temporary queue amq.gen.XXX has been created automatically, to handle the reply. Is it the standard behaviour ? Before using camel-rabbitmq, we were relying on camel-spring-amqp (https://github.com/Bluelock/camel-spring-amqp), which is now obsolete (and triggered the switch to camel-rabbitmq). And with this component, we did not have any temporary queues for this kind of routes. May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? If so, how can I set/adjust it to point on the existing percolate_queue ? Thanks a lot for your answers. Best regards, Guillaume.
Re: [camel-rabbitmq] - InOut pattern and temporary queues
When working with a Request-Reply pattern the reply message needs to send to a second reply queue. The InOut pattern mostly goes like this: 1) Producer send request with correlationid to a queue 2) Consumer receives the message and send a reply to the reply queue 3) Producer matches the reply message through the correlationid and consumes the reply. If there is no matching message a time out is thrown. There are two options for the Reply Queue: 1) Temporary queue. 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" header/parameter. Temporary queues are the default behavior. In general, it's easier to let the correlationid and temporary reply handled by Camel and the Broker. In some cases you need to fall back to fixed reply queues. Regards, Raymond Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < guillaume.fe...@bertin.fr>: > Hi everyone, > > I'm developing an application that relies mostly on Camel (3.9.0) and its > dedicated RabbitMQ / REST components. > My routes are specified in XML (with Spring beans). > > Here's a simple route : > > > > > > > > > > > The percolate_queue defined in another XML contains a single Camel > processor, which returns a basic JSON. > > When I'm calling the REST endpoint : > > * A message is sent to percolate_queue without issues > * The Camel processor is invoked, and returns its value (which I get > as a response for my REST call) > > However, I noticed a temporary queue amq.gen.XXX has been created > automatically, to handle the reply. > Is it the standard behaviour ? > > Before using camel-rabbitmq, we were relying on camel-spring-amqp ( > https://github.com/Bluelock/camel-spring-amqp), which is now obsolete > (and triggered the switch to camel-rabbitmq). > And with this component, we did not have any temporary queues for this > kind of routes. > > May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? > If so, how can I set/adjust it to point on the existing percolate_queue ? > > Thanks a lot for your answers. > > Best regards, > Guillaume. > >
RE: [camel-rabbitmq] - InOut pattern and temporary queues
Hi Raymond, Thanks a lot for this crystal clear answer. I'll let Camel handle theses queues, then ! Best regards, Guillaume. De : ski n Envoyé : mardi 11 mai 2021 15:38 À : users@camel.apache.org Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues When working with a Request-Reply pattern the reply message needs to send to a second reply queue. The InOut pattern mostly goes like this: 1) Producer send request with correlationid to a queue 2) Consumer receives the message and send a reply to the reply queue 3) Producer matches the reply message through the correlationid and consumes the reply. If there is no matching message a time out is thrown. There are two options for the Reply Queue: 1) Temporary queue. 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" header/parameter. Temporary queues are the default behavior. In general, it's easier to let the correlationid and temporary reply handled by Camel and the Broker. In some cases you need to fall back to fixed reply queues. Regards, Raymond Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < guillaume.fe...@bertin.fr>: > Hi everyone, > > I'm developing an application that relies mostly on Camel (3.9.0) and its > dedicated RabbitMQ / REST components. > My routes are specified in XML (with Spring beans). > > Here's a simple route : > > > > > > > > > > > The percolate_queue defined in another XML contains a single Camel > processor, which returns a basic JSON. > > When I'm calling the REST endpoint : > > * A message is sent to percolate_queue without issues > * The Camel processor is invoked, and returns its value (which I get > as a response for my REST call) > > However, I noticed a temporary queue amq.gen.XXX has been created > automatically, to handle the reply. > Is it the standard behaviour ? > > Before using camel-rabbitmq, we were relying on camel-spring-amqp ( > https://github.com/Bluelock/camel-spring-amqp), which is now obsolete > (and triggered the switch to camel-rabbitmq). > And with this component, we did not have any temporary queues for this > kind of routes. > > May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? > If so, how can I set/adjust it to point on the existing percolate_queue ? > > Thanks a lot for your answers. > > Best regards, > Guillaume. > >
Re: [camel-rabbitmq] - InOut pattern and temporary queues
Hi Guillaume, Yes, that’s probably the easiest way. To complete a little: - the correlation can be done on the request message id using a temp destination - the correlation can be done on the client ID using physical destinations Most of the time, ReplyTo header contains a physical response destination, where we correlate with the request message ID. Regards JB > Le 11 mai 2021 à 15:42, FERRY, Guillaume a écrit : > > Hi Raymond, > > Thanks a lot for this crystal clear answer. > I'll let Camel handle theses queues, then ! > > Best regards, > Guillaume. > > De : ski n > Envoyé : mardi 11 mai 2021 15:38 > À : users@camel.apache.org > Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues > > When working with a Request-Reply pattern the reply message needs to send > to a second reply queue. The InOut pattern mostly goes like this: > > 1) Producer send request with correlationid to a queue > 2) Consumer receives the message and send a reply to the reply queue > 3) Producer matches the reply message through the correlationid and > consumes the reply. If there is no matching message a time out is thrown. > > There are two options for the Reply Queue: > > 1) Temporary queue. > 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" > header/parameter. > > Temporary queues are the default behavior. In general, it's easier to let > the correlationid and temporary reply handled by Camel and the Broker. In > some cases you need to fall back to fixed reply queues. > > Regards, > > Raymond > > > > > Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < > guillaume.fe...@bertin.fr>: > >> Hi everyone, >> >> I'm developing an application that relies mostly on Camel (3.9.0) and its >> dedicated RabbitMQ / REST components. >> My routes are specified in XML (with Spring beans). >> >> Here's a simple route : >> >> >> >> >> >> >> >> >> >> >> The percolate_queue defined in another XML contains a single Camel >> processor, which returns a basic JSON. >> >> When I'm calling the REST endpoint : >> >> * A message is sent to percolate_queue without issues >> * The Camel processor is invoked, and returns its value (which I get >> as a response for my REST call) >> >> However, I noticed a temporary queue amq.gen.XXX has been created >> automatically, to handle the reply. >> Is it the standard behaviour ? >> >> Before using camel-rabbitmq, we were relying on camel-spring-amqp ( >> https://github.com/Bluelock/camel-spring-amqp), which is now obsolete >> (and triggered the switch to camel-rabbitmq). >> And with this component, we did not have any temporary queues for this >> kind of routes. >> >> May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? >> If so, how can I set/adjust it to point on the existing percolate_queue ? >> >> Thanks a lot for your answers. >> >> Best regards, >> Guillaume. >> >>
