Mariusz sent the following to me directly (he’s having trouble with the mailing
list).
Hi,
First of all, you seem to have mixed the terms up a bit. "true" and "false"
work the other way than you described, aren't they?
Also: did you mean setting those on the consumer ("from") or producer ("to")
side?
And lastly: camel does not send the reply at the end of the route (hence my
OP!), it sends it in the middle.
Just to recap - as this might be important - my route works as follows:
1) it processes the requests as MyRequest object,
2) then splits them into smaller Messages,
3) sends them to a REST service,
4) unmarshalls as MyResponse objects,
5) aggregates into a bulk object,
6) then processes it and turns into a text message at the end of the route
Camel uses JMSReplyTo destination and send an object of type MyRequest (between
steps 1 and 2), which is clearly not the end of my route.
What is wrong here?
My responses are:
I did switch the true and false settings for disableReplyTo - my bad.
I would assume you’re looking for the JMS request/response functionality from
the consumer (the from), and you’d like the “aggregated bulk object” from step
5 above sent as the response to the JMSReplyTo queue. If it was working the
way I remembered, you wouldn’t need the to(jms…) at the end at all. I’m
wondering if the sub-routes created but the split are effecting the
functionality? Can you try a simple test with out the split and see if it
behaves as expected?
> On Jun 4, 2019, at 8:32 AM, Quinn Stevenson <qu...@pronoia-solutions.com>
> wrote:
>
> 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 <newsletters.t...@gmail.com>
>> 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.
>
