Hi Try to think how you would write the java api for the message transformation without Camel. What would the input and output's be etc.
Then try to write unit test for these transformation that dont use Camel if possible. When using beans the return type is the message body, and as such if you need to enrich with message headers as well, you can bind the @Headers Map as parameter and add your headers on this. But if you are comfortable with the Camel API on Exchange then a processor is fine as well. It just has a direct dependency on Camel and is more low level, eg you need to know about IN vs OUT message etc. And from the code you cannot see what is the expected input and output java/data types etc. A processor however is faster at runtime as its just a direct method call, where as a bean is called using a bit of reflection to find the relevant method and then bean bindings etc. For people whom care about CPU cycles. But the overhead is negligible. On Fri, Apr 14, 2017 at 10:39 PM, DariusX <[email protected]> wrote: > The "Camel in Action" book says "Prefer to use beans over processors" (pg 112 > in 2nd Edition), because they're not dependent on the Camel API. > > This leads me to a follow-up question: > - if we need to tranform between 2 custom formats (i.e. annot use an > existing Dataformat);and, > - also do not need the Exchange, but can transform the body > > With those assumptions, should we also prefer to use Beans over a > Custom-Dataformat or Camel Transformer? Or, are their situations where those > two are useful even if one does not need anything but the body() ? > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Transformation-options-tp5797759.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
