Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.215.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <15576CD8-D8C5-4108-AC37-AD765F04FE4D@planet57.com>
References: <60D0E5A4-8A14-43AE-B311-8BBD5E4ACFB4@planet57.com>
 <4ED5E0D2.9030903@gmail.com>
 <15576CD8-D8C5-4108-AC37-AD765F04FE4D@planet57.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Thu, 1 Dec 2011 20:07:58 +0100
Message-ID: 
 <CAGB5yNm+1U0KpV_R05bk6gLECqLhOZqgV1qgP7UpwANBpNRqJw@mail.gmail.com>
Subject: Re: How to implement dynamic JmsConstants.JMS_DESTINATION_NAME
 w/Processor component?
To: users@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi

Seems a bit odd, as using a Processor gives you directly access to the
Exchange, so if you add an header on the Exchange, then it ought to be
there, when the JmsProducer is invoked.

Could you check whether the exchange has also an OUT message in the process=
or?
But it should really not have that, as Camel uses the
pipes-and-filters EIP by default
http://camel.apache.org/pipes-and-filters

See this FAQ
http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html

Btw did you write which Camel version you are using?


On Wed, Nov 30, 2011 at 9:21 PM, Jason Dillon <jason@planet57.com> wrote:
> On Nov 29, 2011, at 11:52 PM, Willem Jiang wrote:
>>> I spent a few hours (I think again) trying to implement a dynamic
>>> destination based on IN message using a Processor only to find out
>>> that it didn't work as I expected. =A0Quite possible because I don't
>>> understand the full contract for what a processor component needs to
>>> do. =A0I did find that using a bean() component worked, but I'd really
>>> like to avoid any reflection overhead involved. =A0I simply need to
>>> filter the messages passed to a route so I can select the correct
>>> destination. =A0I figured a processor was the way to do this, but
>>> simply adding a processor and setting the IN.header didn't work,
>>> actually it messed up the in message that ended up at the jms
>>> component (had null body, no headers).
>> I need to have a look at your processor code :)
>
> I basically did what the example showed on this page http://camel.apache.=
org/jms.html, except in a processor instead of a pojo:
>
> <snip>
> public class DestinationSelector
> =A0 =A0implements Processor
> {
> =A0 =A0@Override
> =A0 =A0public void process(Exchange exchange) throws Exception {
> =A0 =A0 =A0 =A0checkNotNull(exchange);
> =A0 =A0 =A0 =A0Message message =3D exchange.getIn();
> =A0 =A0 =A0 =A0EventMessage event =3D message.getBody(EventMessage.class)=
;
> =A0 =A0 =A0 =A0String name =3D String.format(TOPIC_FORMAT, event.getRepoI=
d());
> =A0 =A0 =A0 =A0message.setHeader(JmsConstants.JMS_DESTINATION_NAME, name)=
;
> =A0 =A0}
> }
> </snip>
>
> And then hooked it up with:
>
> <snip>
> camel.addRoutes(new RouteBuilder()
> {
> =A0 =A0@Override
> =A0 =A0public void configure() throws Exception {
> =A0 =A0 =A0 =A0from("direct:dispatch")
> =A0 =A0 =A0 =A0 =A0 =A0.routeId("route1")
> =A0 =A0 =A0 =A0 =A0 =A0.process(new DestinationSelector())
> =A0 =A0 =A0 =A0 =A0 =A0.to("local-jms:topic:ignored"); // calculated by s=
elector
> =A0 =A0}
> });
> </snip>
>
> This didn't work, and debugging the JmsProducer shows that the in message=
 body is null.
>
> Using a pojo does work however:
>
> <snip>
> public class DestinationSelector
> {
> =A0 =A0public void select(final Exchange exchange) throws Exception {
> =A0 =A0 =A0 =A0checkNotNull(exchange);
> =A0 =A0 =A0 =A0Message message =3D exchange.getIn();
> =A0 =A0 =A0 =A0EventMessage event =3D message.getBody(EventMessage.class)=
;
> =A0 =A0 =A0 =A0String name =3D String.format(TOPIC_FORMAT, event.getRepoI=
d());
> =A0 =A0 =A0 =A0message.setHeader(JmsConstants.JMS_DESTINATION_NAME, name)=
;
> =A0 =A0}
> }
> </snip>
>
> hooked up with:
>
> <snip>
> camel.addRoutes(new RouteBuilder()
> {
> =A0 =A0@Override
> =A0 =A0public void configure() throws Exception {
> =A0 =A0 =A0 =A0from("direct:dispatch")
> =A0 =A0 =A0 =A0 =A0 =A0.routeId("route1")
> =A0 =A0 =A0 =A0 =A0 =A0.bean(new DestinationSelector())
> =A0 =A0 =A0 =A0 =A0 =A0.to("local-jms:topic:ignored"); // calculated by s=
elector
> =A0 =A0}
> });
> </snip>
>
> However I believe this will have to employ some reflection to invoke, whi=
ch I'd rather avoid if possible.
>
>
>>> Is the processor intended to set the out message, and that out
>>> message would then be used as the in message for the next step?
>>
>> Yes, camel pipeline process will copy the out message to next exchange i=
n message if you set the out message body.
>
> What is special about the bean() method vs. the process() method that all=
ows it to work and the processor to fail?
>
>
>>> I'm just looking for the most efficent way to implement "Reuse
>>> endpoint and send to different destinations computed at runtime" (
>>> http://camel.apache.org/jms.html )... just a direct invocation that
>>> gets the Exchange (like a Processor does) w/o the bean
>>> introspection/invocation overhead.
>>
>> I think you can set the message header in the processor as the bean does=
.
>
> The same code doesn't work in a processor... which is why I'm confused :-=
(
>
> If you, or anyone really, could help explain why one works and the other =
fails it would be a big help :-)
>
> Thanks,
>
> --jason
>
>


--=20
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/