A combination of beans and processors can help prevent tight coupling to
the Camel API. Now I don't personally do this since I really like Camel, so
I don't mind the hard dependency (plus we tend to use the annotations with
beans).
On 18 September 2014 00:00, Jan Matèrne (jhm) <apa...@materne.de> wrote:
> With bean you could also get the whole exchange, so in that case you could
> do the same as with a processor.
> Another advantage is that you extract the logic (the HOW) from the route
> and
> there only stays a (hopefully) meaningful bean name (the WHAT).
>
> Jan
>
>
>
> from("...")
> .bean(DoubleSallary.class)
> .to("...")
>
> instead of
>
> from("...")
> .process(new Processor() {
> public void process(Exchange exchange) {
> // a long implementation comes here
> }
> }).
> .to("...")
>
> > -----Ursprüngliche Nachricht-----
> > Von: pradeep [mailto:pradeepnc...@gmail.com]
> > Gesendet: Donnerstag, 18. September 2014 05:48
> > An: users@camel.apache.org
> > Betreff: Re: Preferring bean or processor invocations on a route
> >
> > They are very similar, but a Processor is more limited than using
> > Beans. We can use Processor for simpler use cases that just interact
> > with the Exchange, etc. Also, inline processors in camel route are a
> > great way to interact in route without having to create a separate
> > class.
> >
> > Beans provide more flexibility and also support a true POJO approach.
> > This allows you to more easily integrate with existing APIs. Good
> > support of annotations like @headers, @header and @body. So most of the
> > exchange items can be accessed
> >
> > Beans also provide great features/flexibility with regards to Camel
> > routing/EIP integration
> >
> >
> >
> > --
> > View this message in context:
> > http://camel.465427.n5.nabble.com/Preferring-bean-or-processor-
> > invocations-on-a-route-tp5756652p5756666.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Matt Sicker <boa...@gmail.com>
