You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by David Yang <da...@coverago.com> on 2010/10/01 00:25:57 UTC
How to handle firefox outputting files, as component?
We're still getting to know Camel but one of the things we'd like to try is to have a step in our pipeline where HTML data (or a file location) is passed to firefox and converted to PDF. We'd like to probably pass a location on disk or perhaps just the entire HTML as data.
How should we go about implementing this? Should the firefox PDF generator be a Component or Processor?
I'm imagining something like this:
from("file://myhtmlfiles").to("firefoxpdf:///usr/bin/firefox").to("file://mypdffiles")
Thanks for any ideas,
David
Re: How to handle firefox outputting files, as component?
Posted by Bruno Borges <br...@gmail.com>.
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 <da...@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.
>
>
Re: How to handle firefox outputting files, as component?
Posted by David Yang <da...@coverago.com>.
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.
Re: How to handle firefox outputting files, as component?
Posted by Richard Kettelerij <ri...@gmail.com>.
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.