camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Borges <bruno.bor...@gmail.com>
Subject Re: How to handle firefox outputting files, as component?
Date Fri, 01 Oct 2010 19:57:48 GMT
Usually, files are not transported inside the message. They are written to
the disk and a reference to it is then exchanges (java.io.File).

I guess you will have no problem about that.

Cheers
Bruno Borges
www.brunoborges.com.br
+55 21 76727099

"The glory of great men should always be
measured by the means they have used to
acquire it."
 - Francois de La Rochefoucauld



On Fri, Oct 1, 2010 at 4:54 PM, David Yang <david.yang@coverago.com> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message