axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <>
Subject Re: Is there a smarter way to solve this issue?
Date Fri, 14 Nov 2008 04:08:25 GMT

> 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?

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 

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?.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message