That's where I ended up too. I was minded to make onPrepare a fragment for embedding into wiretap too however one might imagine that someone using wiretap does not want to modify the exchange based on individual onward paths.
So in our case multicast() may be more appropriate with stopOnException() to handle a custom response should the JMS route in the middle fail. On 5 February 2015 at 09:59, Morgan Hautman <morgan.haut...@gmail.com> wrote: > James, > > It seems to be documented here: http://camel.apache.org/multicast.html > (end of page) > > And the class they use: > https://github.com/apache/camel/blob/master/camel-core/ > src/test/java/org/apache/camel/processor/AnimalDeepClonePrepare.java > > Regards, > Morgan > > > On 5/02/2015 10:38, James Green wrote: > >> Yes this is the simple bit. >> >> The not so simple bit is appreciating what happens under the hood. >> wiretap, >> quite rightly, sends the same object references down each path. If one of >> those paths mutates the Exchange's Message, the other routes will spot the >> change and the developer gets a rude surprise. >> >> Under these circumstances I presume the onPrepare to clone the Exchange is >> required? It's not overly well documented on the wiretap page. >> >> James >> >> >> On 4 February 2015 at 06:11, Claus Ibsen <claus.ib...@gmail.com> wrote: >> >> On Tue, Feb 3, 2015 at 2:30 PM, James Green <james.mk.gr...@gmail.com> >>> wrote: >>> >>>> Nope :) >>>> >>>> rest("/from-smtp/") >>>> .post() >>>> .type(EmailedSmsRequest.class) >>>> .to("direct:fromSmtp"); >>>> >>>> direct:fromSmtp routes onward to direct:router. direct:router sends it >>>> onwards to jms:queue:foo asynchronously. The route that reads >>>> from("direct:router") is intended for be fully re-usable and has >>>> multiple >>>> public interfaces sending messages into it but is not expected to reply >>>> >>> at >>> >>>> all (except for raising exceptions of course). >>>> >>>> Beyond direct:fromSmtp routing to direct:router, I want to set the OUT >>>> >>> part >>> >>>> of the exchange so that the rest component knows what to send back to >>>> the >>>> http client. >>>> >>>> Then do additional routing after, eg to set the OUT part you want >>> >>> >>> >>> I suspect I can wiretap() to split the messaging across two routes - one >>>> >>> to >>> >>>> direct:router and the other to processing that provides the OUT part of >>>> >>> the >>> >>>> exchange however it doesn't feel entirely natural hence I didn't think >>>> of >>>> it myself. >>>> >>>> [ I have not yet tried wiretap in the code I'm asking the question >>>> about, >>>> will do shortly ] >>>> >>>> >>>> >>>> On 3 February 2015 at 13:20, Morgan Hautman <morgan.haut...@gmail.com> >>>> wrote: >>>> >>>> Yes I understand we can encounter a timeout when we don't respond to >>>>> http/rest because it's synchronous. >>>>> >>>>> But I think what James means is : >>>>> >>>>> 1st route: >>>>> from(cxf:...).to(activemq:bar) >>>>> >>>>> 2nd route >>>>> from(activemq: bar).to(processing) >>>>> >>>>> The first route sends a message to the second route through activemq >>>>> and >>>>> waits for the second route to process the message and the second route >>>>> respond to the first route who will answer to the client what "route2" >>>>> responded. (timeout or not) >>>>> >>>>> Hope It's comprehensive. >>>>> >>>>> PS: I'm not in James team, I just try to help and understand a problem >>>>> I >>>>> had myself some months ago but didn't look further. >>>>> >>>>> >>>>> On 3/02/2015 13:54, Claus Ibsen wrote: >>>>> >>>>> On Tue, Feb 3, 2015 at 1:27 PM, Morgan Hautman < >>>>>> >>>>> morgan.haut...@gmail.com> >>> >>>> wrote: >>>>>> >>>>>> Claus, >>>>>>> >>>>>>> Is their any way a queue (using activemq) could respond , like a >>>>>>> request-reply mechanism? >>>>>>> >>>>>>> http://camel.apache.org/request-reply.html >>>>>>> >>>>>>> Not sure I follow. Camel can do InOnly and InOut over JMS. So yeah >>>>>>> >>>>>> both is possible. >>>>>> >>>>>> Just mind that a client like HTTP / REST is synchronous in that sense >>>>>> the client awaits a response, so whether that is just a OK or to >>>>>> respond with some new data, then that needs to happen, and occurs when >>>>>> the exchange is done being routed, and the control is back at the >>>>>> consumer. >>>>>> >>>>>> On 3/02/2015 13:14, Claus Ibsen wrote: >>>>>> >>>>>>> Hi >>>>>>>> >>>>>>>> You can send the message to the JMS as InOnly or use WireTap >>>>>>>> >>>>>>>> On Tue, Feb 3, 2015 at 12:27 PM, James Green < >>>>>>>> >>>>>>> james.mk.gr...@gmail.com> >>> >>>> wrote: >>>>>>>> >>>>>>>> I have two routes: >>>>>>>>> >>>>>>>>> 1. A rest dsl accepting data from HTTP clients and sending it to >>>>>>>>> the >>>>>>>>> route >>>>>>>>> below before replying to the client >>>>>>>>> 2. A "backend" route that receives an Exchange and sends it to a >>>>>>>>> JMS >>>>>>>>> queue >>>>>>>>> >>>>>>>>> By default, although the JMS queue gets the message, a stack trace >>>>>>>>> occurs >>>>>>>>> because the queue did not respond. So I set the backend route to be >>>>>>>>> InOnly >>>>>>>>> and now no stack trace occurs. >>>>>>>>> >>>>>>>>> However, the remaining part of my rest dsl route does not execute. >>>>>>>>> >>>>>>>>> So how do I accept some REST request, fire off an asynchronous JMS >>>>>>>>> message, >>>>>>>>> and reply to the HTTP client? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> James >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> Red Hat, Inc. >>> Email: cib...@redhat.com >>> Twitter: davsclaus >>> Blog: http://davsclaus.com >>> Author of Camel in Action: http://www.manning.com/ibsen >>> hawtio: http://hawt.io/ >>> fabric8: http://fabric8.io/ >>> >>> >
