camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Custom component Vs Custom processor
Date Wed, 10 Nov 2010 11:47:02 GMT
On 9 November 2010 10:48, unmarshall <> wrote:
> Hi All,
> I have a very basic question. When do you decide to create a custom
> component Vs creating a custom processor. A camel component implementation
> has a processor either in terms of producer or consumer or both.
> The question arose when i looked at the XSLT component. XsltComponent class
> internally uses a processor (XsltBuilder) which then creates and returns a
> special endpoint ProcessorEndpoint. What was the reasoning that went behind
> making it a component instead of direct implementation of a Processor
> interface.
> You can still set xmlConverter, uriResolver properties on a Processor and
> still will not have any state.

I'd even argue that thanks to the nice Bean integration that abstracts
away most Camel specific APIs...

I'd recommend either writing a Component or just using a bean (which
makes it easier and more natural to use Camel's type conversion etc)..

For me the decision comes down to

* do you want producers and consumers of your thing? If so that sounds
like a Component / Endpoint to me. If literally its just a method call
then maybe a bean is more natural - unless...

* does a URI scheme feel a natural way to refer to different endpoints
and configure your thing?

If so using a Component/Endpoint might be a good fit.

e.g. most XSLT transformations are usually the same, bar the odd
parameter here or there, usually the only thing that changes is the
URI of the template. So using a URI of "xslt:someTransform.xsl" feels
much more natural to Camel - its then trivial for someone to also use
"xslt:myOtherTransform.xsl" or even
"xslt:" without having to write a new bean
or figure out some class library configuration to take someone else's
bean and configure it using dependency injection.

If your bean is very complex with quite hairy dependency injection
requirements, then maybe a bean is easier; though even in that case,
you could take one specific complex configuration and make it a
Component then have multiple Endpoints hanging off it. (e.g. JMS is
complex configuration; you might make one JMS component for
WebSphereMQ with a specific JMS ConnectionFactory and another for
ActiveMQ then you've an easy URI to use to refer to queues & topics on

So maybe it boils down to, can you see a useful way to represent your
thing as a set of URIs; if so Component/Endpoint makes sense. If its
only ever going to a very specific thing you invoke in the middle of a
route, a bean sounds fine though.

Twitter: jstrachan

Open Source Integration

View raw message