42

It seems like both serve the same purpose. Is there any difference that makes one useful in certain situations and not the other ?

redben
  • 5,578
  • 5
  • 47
  • 63

2 Answers2

34

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

Ben ODay
  • 20,784
  • 9
  • 45
  • 68
12

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:

  • Bean methods with more than one parameter
  • Trying to get data out of the exchange params / the message headers

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.

Roy Truelove
  • 22,016
  • 18
  • 111
  • 153