Re: Camel Component for the OFTP2 protocol
I suppose the sources are those ones: http://websvn.ow2.org/listing.php?repname=accordpath=/odetteftp/trunk/camel-oftp/ Haven't found any binaries though, even on the sonatype snapshot repo. On Wed, Sep 22, 2010 at 07:16, Hadrian Zbarcea hzbar...@gmail.com wrote: Bruno, I couldn't find the code/jar/doc for the camel-oftp component. Odds are interested users won't either (easily). Your blog post does not show what jars are needed and where to find them either. Did I miss it? Could you please provide directed links? Thanks Hadrian On Sep 21, 2010, at 3:02 PM, Bruno Borges wrote: Hi all! Some of you might know the Odette File Transfer Protocol, also know as OFTP. My work @Neociclo aims to present it to the community and as part of that, I'm introducing now the Camel Component for the Accord Odette, a OFTP2 Java library. If you want to know more, please follow this link: http://bit.ly/aLSitv Also, the project is hosted at http://accord.ow2.org/odetteftp The component is a Maven module of the Accord Odette project. Thank you, 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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Camel Component for the OFTP2 protocol
Hi Hadrian/Guillaume, Yes, there's no binaries yet. We are still adding some features before actually proceeding to an official release. Also I still have to document the component and its parameters on http://accord.ow2.org/odetteftp. By the way, this is the main website for the project. The component is a module of the Accord Odette framework, so if you want to take a look at it, I suggest to check out the code. $ svn checkout svn://svn.forge.objectweb.org/svnroot/accord/odetteftp/trunk I'll keep the Camel mailing list posted about any other news. Best regards, 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 Wed, Sep 22, 2010 at 5:35 AM, Guillaume Nodet gno...@gmail.com wrote: I suppose the sources are those ones: http://websvn.ow2.org/listing.php?repname=accordpath=/odetteftp/trunk/camel-oftp/ Haven't found any binaries though, even on the sonatype snapshot repo. On Wed, Sep 22, 2010 at 07:16, Hadrian Zbarcea hzbar...@gmail.com wrote: Bruno, I couldn't find the code/jar/doc for the camel-oftp component. Odds are interested users won't either (easily). Your blog post does not show what jars are needed and where to find them either. Did I miss it? Could you please provide directed links? Thanks Hadrian On Sep 21, 2010, at 3:02 PM, Bruno Borges wrote: Hi all! Some of you might know the Odette File Transfer Protocol, also know as OFTP. My work @Neociclo aims to present it to the community and as part of that, I'm introducing now the Camel Component for the Accord Odette, a OFTP2 Java library. If you want to know more, please follow this link: http://bit.ly/aLSitv Also, the project is hosted at http://accord.ow2.org/odetteftp The component is a Maven module of the Accord Odette project. Thank you, 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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Endpoint consumer created only on from()
It is where I am right now. The OFTP protocol states that is the sever who will let the client know about incoming files. What I'm doing now is remodeling the consumer (pollingConsumer) to first ask the route if it wants to receive a file before actually downloading it. So every poll will produce first an InOut message per file. The component will let the route accept or reject the incoming file by faulting the message or not, and to set in the Out message body an object of type File or OutputStream. If the route does not override store location with an OutputStream, consumer will exchange an InOnly message containing a GenericFileFile. If this is not the case (route did override store location with an OutputStream), then a second InOnly message containing metadata about that file will be sent to the route. What do you think? 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 Wed, Sep 22, 2010 at 2:36 AM, Hadrian Zbarcea hzbar...@gmail.com wrote: The question is more what MEP does the remote server use. The choices you exposed seem to imply that the remote server would return incoming files, which would be an InOut. However, an ftp server or file system (an smtp server as well) use an InOnly pattern (on the producer side) so there is no response (or incomingFile). By not populating an out in the Exchange, camel will automatically send the original message (from the outbox) to the rest of the route, therefore you don't need to do anything on that side. To use incomingFiles you would need a PollingConsumer. That would be the enabler for the second route in Claus' example. Hadrian On Sep 22, 2010, at 12:32 AM, Claus Ibsen wrote: On Tue, Sep 21, 2010 at 8:24 PM, Bruno Borges bruno.bor...@gmail.com wrote: So, considering this route: from(file:/outbox).to(someRemoteServer).to(file:/home/inbox); What do you consider to be a better design: 1- a) files from outbox goes to remoteServer-producer b) remoteServer-producer sends file to remote connection c) remoteServer-endpoint forward remote incomingFiles to this route rather files from outbox 2- a) files from outbox goes to remoteServer-producer b) remoteServer-producer sends file to remote connection c) remoteServer-endpoint continue processing files from outbox to the rest of this route It really depends what the removeServer protocol is? Is it a file based then I would assume it would be more correct to do as the regular file/ftp does which would be. from(file:/outbox).to(someRemoteServer); from(someRemoteServer).to(file:/home/inbox); To have it in 2 routes. One as the producer, and the other as the consumer. They can work independent. And if you do this in Camel from(file:/outbox).to(someRemoteServer).to() Then you can continue route the file to as well if you need it. 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 Tue, Sep 21, 2010 at 2:57 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Tue, Sep 21, 2010 at 7:17 PM, Bruno Borges bruno.bor...@gmail.com wrote: Is this statement correct? Are all endpoint's consumers only created when Endpoint is referenced by a from() ? consumers is created when they are needed. And from(xx) is created a consumer on endpoint xxx. Where as to(xxx) is created a producer on endpoint . 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 -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Using route as template to create dynamic routes
Hi, Here is what I need, I suspect it is possible with camel but cannot figure out how to achieve it. If anyone can give me some leads on how to achieve this. I have multiple routes, one of which is as below. camel:route camel:from uri=queue:somequeue / camel:to uri=bean:someBean / camel:to uri=someProcessor / /camel:route Depending on the environment, there can be more than entry points i.e. multiple queue's to consume from. For ex: on QA env there is only 1 queue, on Production there are 3 queues. I see there are loadbalancer and dynamicRouter component but those are only used in to part of route (atleast from examples I see). So I was wondering if I can create routes dynamically using above route as template. On start up, look at number of queue's and than for each queue create copy of above route. Or is there any better way to do this? Thanks! -- View this message in context: http://camel.465427.n5.nabble.com/Using-route-as-template-to-create-dynamic-routes-tp2850206p2850206.html Sent from the Camel - Users mailing list archive at Nabble.com.
Managing configuration in components, routes, projects
I'm curious how others are solving the problem of managing configuration across various routes, components etc inside a Camel Context. We've written some Components that themselves need to have connections to various DB's etc. If we want to have a development and production properties for each one of those (so that they can be individually run/tested) but then use those Components in separate Route projects and a master CamelContext, what would you recommend. They have other dependencies as well (directory locations, file resources, application binaries). Basically, if this is my world, where should I keep all the configuration properties? Master Context - Route 1 - Comp A - Comp B - Route 2 - Comp A' (A with diff configuration) - Comp C I've thought about using JNDI, Jconfig or having some huge overwritable map Singleton. Any thoughts/ideas? Would really like hearing how others are solving this. David
Re: Managing configuration in components, routes, projects
I'm using Spring.
PropertyPlaceholder magic makes Spring config vary based on deployment.
At a high level, the recipe is as follows. RouteBuilder rather than
SpringRouteBuilder as parent class would work fine unless you want to call
things like beanRef() instead of bean().
@Component //make sure route builder gets instantiated
class ... extends SpringRouteBuilder {
@Autowired / @Resource ... to pull in configuration from Spring
@PostConstruct
public void init() throws Exception {
//if needed, register stuff:
this.camelContext.addComponent(jms-opps, this.amqc);
//finally, hook into Camel context:
this.camelContext.addRoutes(this);
}
Cheers
-Lorrin
On Sep 22, 2010, at 1:41 PM, David Yang wrote:
I'm curious how others are solving the problem of managing configuration
across various routes, components etc inside a Camel Context.
We've written some Components that themselves need to have connections to
various DB's etc. If we want to have a development and production properties
for each one of those (so that they can be individually run/tested) but then
use those Components in separate Route projects and a master CamelContext,
what would you recommend. They have other dependencies as well (directory
locations, file resources, application binaries).
Basically, if this is my world, where should I keep all the configuration
properties?
Master Context
- Route 1
- Comp A
- Comp B
- Route 2
- Comp A' (A with diff configuration)
- Comp C
I've thought about using JNDI, Jconfig or having some huge overwritable map
Singleton. Any thoughts/ideas? Would really like hearing how others are
solving this.
David
