Thanks for the response Richard - was very helpful.
Any sense of how large exchange message bodies can get? Should we use that
itself as the transfer mechanism or have some other form of transport?
I'm also curious if we want to reuse a bunch of these components we're creating
across various projects and also share them with the community, what's the best
way to bundle them up?
David
On Sep 30, 2010, at 8:11 PM, Richard Kettelerij wrote:
>
> A Camel component is essentially a processor. In general components are more
> suitable for reusable pieces of integration logic (like wrapping transports
> such as ftp, tcp, ws, etc) while processors are more suitable for adhoc
> tasks that you want to perform as part of your route (like validating the
> payload of a message or some custom transformation).
>
> The question to ask whether you should build a component or a processor is:
> do you want to (re)use the Firefox PDF functionality in other, possibly
> future, routes? If so, you're probably beter of writing a component since it
> allows for better encapsulation of the pdf-to-html conversion logic. Most
> notably because the component has a well defined interface as illustrated in
> your example ("firefoxpdf:///usr/bin/firefox").
>
> But remember, writing a component is a bit more work than writing a
> processor (e.g. more interfaces to implement). If your pdf-to-html
> conversion is specific to some route a processor such as the one given below
> will suffice.
>
> from("file://myhtmlfiles").process(new Processor() {
> public void process(Exchange exchange) throws Exception {
> // classes are just for illustration
> Converter converter = new FirefoxConverter();
> Html html =
> converter.convertToHtml(exchange.getIn().getBody());
> exchange.getIn().setBody(html);
> }
> }).to("file://mypdffiles")
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/How-to-handle-firefox-outputting-files-as-component-tp3047751p3047804.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
