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