When I first started using Camel, I thought it was strange that the mongodb component returned data via <to ..> instead of <from ..>. Eventually I figured it out. BTW, I still haven't memorized the definitions of producer and consumer in Camelspeak because I can't keep them straight.
Similar to your message queue example, I load data from the mail component on-demand. I create a route on the fly and remove it when all mail has been consumed (I had to modify the component to make that happen - I will submit a patch when I have implemented something that doesn't look like botched surgery and I have finished other mods). Anyone who has ever tried removing a route knows that it ain't pretty. Underneath the covers, the overhead in terms of memory and other resources (eg thread) of creating and removing routes is not trivial. I think <from ..> has its place (asynchronous 'static' processing - such as reading from the same JMS queue for eternity) but component designers need to support <to ..> as well, like the mongodb example. If "dynamic on-demand <from" will be possible in Camel 3.0, that would be fantastic. ~cg On Wed, Jun 4, 2014 at 10:36 PM, Claus Ibsen <[email protected]> wrote: > On Thu, Jun 5, 2014 at 2:06 AM, Henrique Viecili <[email protected]> > wrote: > > I faced the same issue in similar scenarios which forced me to use Claim > > Check in the aggregation strategy. I cannot recall exactly the reason, > but > > if I'm not wrong a while ago Claus commented about this limitation here > in > > the mailing list. > > > > Yeah see the content enricher eip page, about pollEnrich, and the red > box on that page. > And we got a JIRA ticket to improved this. But requires an API change > for Camel 3.0. > > > > Anyway, it would be a great improvement. > > > > Regards, > > Henriqeu Viecili > > > > Henrique Viecili > > > > > > On 5 June 2014 00:47, kraythe . <[email protected]> wrote: > > > >> I am working on some routes which use servlet: endpoints to create a > REST > >> api for a Ajax UI application. While working on it I am constantly > plagued > >> by the thought that there is a missing use case, a massive one in camel. > >> > >> Suppose you want to serve a file to a user. They send you some parameter > >> and you use that to select the appropriate file to return. Currently > there > >> is no way to do such a thing with camel, so you are forced to use a > >> processor and implement the logic yourself. What you need to do is > enrich > >> the current exchange with information from outside that exchange but in > a > >> consumer manner. What you really need is something like: > >> > >> from("servlet:downloadFile") > >> // logic to figure out what filename > >> .enrich("file://a/b/c") > >> .end(); > >> > >> Sure this particular use case can be implemented with a processor: > >> > >> from("servlet:downloadFile) > >> // logic to figure out what filename > >> .process(new Processor() { > >> public void process(final Exchange exchange) { > >> // code to create an IOStream and set it as body. > >> } > >> } > >> > >> This is an acceptable workaround in this case but it violates the > beautiful > >> component architecture. If I wanted to enrich from a JMS queue > >> ("servlet:nextTicket") I would have to implement queue connectivity > myself. > >> Less than sub par. > >> > >> It seems to me that camel needs to have a new use case "consumeEnrich()" > >> where a consumer can be fired and then aggregated into the current > >> exchange. In order to support this we need to add the ability for > on-demand > >> consumption: i.e. > >> > >> public interface SupportsConsumeEnrich { > >> public Exchange consumeNow(); > >> } > >> > >> Any endpoint that then implements SupportsConsumeEnrich can then be > used in > >> the consumeEnrich DSL. What do you think? > >> > >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > >> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > >> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > >> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>* > >> > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: [email protected] > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > hawtio: http://hawt.io/ > fabric8: http://fabric8.io/ >
