On 9 November 2010 10:48, unmarshall <unmarsh...@gmail.com> 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... http://camel.apache.org/bean-binding.html 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:http://foo.com/something.xsl"; 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 each). 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. -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
