Preferring bean or processor invocations on a route

[Craig Taylor]

I've seen a number of web statements by individuals favoring the bean()
invocations over calling a processor. I believe the arguments / rational
stated is that of simplicity, interaction with other libraries etc.

I personally prefer processor in that it allows me to alter / affect more
than just the result body, eg: properties and headers. I'm not aware of any
means to do this within a bean() invocation.

Can this be done and is there any rational of choosing one over the other?

[Willem Jiang]

Hi,

Camel bean just provides a good application layer for the user to inject their business logic, so the user won’t need to deal with processor and exchange in their code.

If you want to read about the message header and properties, please take some time to check out the bean binding[1] page. The only short coming is you bean method cannot change the exchange directly.  

[1]http://camel.apache.org/bean-binding.html

--
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

Post by Craig Taylor
I've seen a number of web statements by individuals favoring the bean()
invocations over calling a processor. I believe the arguments / rational
stated is that of simplicity, interaction with other libraries etc.
I personally prefer processor in that it allows me to alter / affect more
than just the result body, eg: properties and headers. I'm not aware of any
means to do this within a bean() invocation.
Can this be done and is there any rational of choosing one over the other?
--
-------------------------------------------
Craig Taylor

[pradeep]

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

[Jan Matèrne (jhm)]

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-----
Gesendet: Donnerstag, 18. September 2014 05:48
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
exchange items can be accessed
Beans also provide great features/flexibility with regards to Camel
routing/EIP integration
--
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]

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).

Post by Jan Matèrne (jhm)
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-----
Gesendet: Donnerstag, 18. September 2014 05:48
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
exchange items can be accessed
Beans also provide great features/flexibility with regards to Camel
routing/EIP integration
--
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.