Menu
It seems like both serve the same purpose. Is there any difference that makes one useful in certain situations and not the other ?
317
The Processor is used for processing message Exchanges. The processor is a core Camel concept that represents a node capable of using, creating, or modifying an incoming exchange.
Bean as endpointThe source for the bean is just a plain POJO: Camel will use Bean Binding to invoke the sayHello method, by converting the Exchange's In body to the String type and storing the output of the method on the Exchange Out body.
Apache Camel ™ is a versatile open-source integration framework based on known Enterprise Integration Patterns. Camel empowers you to define routing and mediation rules in a variety of domain-specific languages (DSL, such as Java, XML, Groovy, Kotlin, and YAML).
In practice, they are very similar, but a Processor is more limited than a Bean. I generally use a Processor for simple use cases that just interact with the Exchange. Also, inline processors are a great way to interact 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 (just need to convert the inputs/outputs to match, etc).
Beans also provide great features/flexibility with regards to Camel routing/EIP integration, including...
rich set of bindings that allow you to quickly bind data from the Exchange to attributes of a bean method, etc.
POJO consuming/producing allow you to interact with endpoints in a reusable manner
used as expressions/predicates (for POJO EIP implementation...filters, etc)
87
Boils down to a matter of preference, I'd say. I generally opt for the POJO approach and so I started using beans to do my processing, but over time I've slowly moved to using Processors.
I was feeling pain in the following cases:
I know that Camel 2.8 takes out some of the pain of these cases by allowing annotations in your bean which guide Camel on how to call your bean's methods. I didn't want to go this route -- felt wrong to put Camel annotations into a bean that shouldn't care that it's being called by Camel.
In the end we created an annotation-free, client-agnostic bean and a very thin Processor that pulls everything it needs from camel and passes it to that bean.
Just my 2 cents - the bean route really isn't a bad one - it'll do the job just as well (esp in 2.8)
EDIT
Many improvements have been made to camel's use of POJOs to process messages since this was written - this answer may no longer be applicable.
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
