It is nice to see that someone has the problem. We are doing it the same way (with a jms router so to speak - it is actually our own action).
I tried making the ESB unware client setting the reply-to of the JMS message to the ESB JMS Gateway but I think the esb is ignoring it.
Just had a look at the JmsGatewayListener and it sends it message asynchronous. This means that if you want request-response you need to build your own synchronous JmsGatewayListener. Putting a reply-to onto the message won't help since the serviceInvoker is using an asynchronous call.
Yes - I did notice that as well. Seems like a doable solution would be to build out a custom JmsGatewayListener to either take the response queue as config, or read queue name from jmsReplyTo, and ship the unwrapped response from deliverSync() to it. But, I was wondering if there were good reasons not to do something like that (ie ESB's "design center", other known/better implementations of EIPs like this, etc).
I will have a go at this approach.
That sound nice. How do you make jboss-esb.xml understand your new gateway listener?
That seems to be the challenge!
For now, I am just building a custom gateway listener and will plug it in via <listener>. The problem with this approach is that you can't link to <jms-bus>, only <bus>, so I will pass all the JMS config stuff in with KV config pairs. Good enough for a prototype.
Currently the JMS listener classname is hardcoded in JmsMapper, so the longer term options are to change org.jboss.soa.esb.listeners.gateway.JmsGatewayListener or add support in <*-listener> to support declaring a classname for the listener class. The latter IMO is the best solution but requires a bit more investment of time, and I'd like to see if that's practical over in dev forum.
The information should be stored in the ESB message and, assuming it reaches the far end, can be used from the JMS notifiers