It’s been a while since I’ve implemented a route that implements JMS request-response, but if I remember correctly, you need to choose whether Camel/Spring will handle the reply or you will.
If you set disableReplyTo=true, Camel/Spring will send the reply using whatever is in the exchange at the end of the route (so you don’t need the “to” at the end of the route). If you set disableReplyTo=false, then you’re responsible for taking the appropriate action with the message. HTH > On Jun 4, 2019, at 3:18 AM, Mariusz Kosecki <[email protected]> > wrote: > > Hello, > My route is as follows: > > from("jms:topic:T.INPUT?disableReplyTo=false") > .process(requestProcessor) > .unmarshal().json(JsonLibrary.Jackson, MyRequest.class) > .split(messageSplitter) > .process(restProcessor) > .unmarshal().json(JsonLibrary.Jackson, MyResponse.class) > .aggregate(messagesAggregator) > .process(responseProcessor) > .to("jms:topic:recipientTopic"); > > If I set disableReplyTo=true and convert JMSReplyTo into > CamelJmsDestinationName, I get the expected result: process the request and > send the response to the output topic. > But I cannot comprehend why would I need to disable reply to, when in fact > I want to utilise it. > Currently, when disableReplyTo is set to false, I will end up a gibberish > message on the output topic, which cannot be parsed and throws an exception > "ClassNotFoundException: (package name).MyRequest" - it seems that camel > utilises JMSReplyTo between the first unmarshal() and split(), which is > unwanted as the message processing is incomplete. Is this a bug? Is this > explicitly documented somewhere? Am I doing something wrong? Are there too > many steps in the route? Can anyone explain? > > Kind regards.
