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/
