If you want to modify the replyTo at the transport level, for me it indicates something is wrong some where. Can you please explain your requirement in more detail?
Supun,
In the AMQP transport, the destination queues are generated at the transport level. So the ReplyTo destination is unknown until the transport sender is hit.
Earlier this worked fine as the ReplyTo destination was fixed and it was possible to set it as a client option comfortably. But now when it comes to interoping with the Axis2/Java JMS transport, that is no longer possible as the JMS transport makes use of dynamically generated destinations.
I would also like to raise another issue in our dual-channel implementation. Why we let the client programmer set the reply_to as a client option?. Shouldn't that bit happen implicitly?.
Danushka --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
