I don't see adding a custom header to be a big deal. You have to remember when you are doing multi route processing with JMS in between everything is happening asynchronously. The old semantics you are used to of request-reply are not necessarily appropriate. Asynch programming is much more powerful but a bit of a pain to wrap your head around at first. When I train others to write Camel this is one of the biggest hurdles they have to overcome. Start thinking about your flow not as steps in a process but as processes to be executed perhaps in an order and perhaps with no defined order whatsoever.
*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>* On Tue, Feb 25, 2014 at 1:54 PM, BlackTie <[email protected]> wrote: > I have implemented my proposed solution from my previous post, and it seems > like it will work out. However, performing the aggregation in a separate > route is a bit trickier than using an AggregationStrategy on the multicast > or recipientList themselves. It doesn't look like any of the > headers/properties that allow Camel to correlate the responses in the > AggregationStrategy are available when the aggregation is done on a > separate > route. I was hoping to be able to use Camel-supplied correlation ID and > indexes/counts to make the aggregation seamless, but I've resorted to > adding > my own headers for this. > > Is anyone else doing aggregation in a route separate from the route with > the > recipientList or multicast? Have you found an easier way to aggregate than > what I'm currently doing? > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Is-there-an-alternative-to-request-reply-when-you-want-to-use-JMS-transactions-tp5747691p5747962.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
