On Fri, 2008-11-14 at 09:38 +0530, Danushka Menikkumbura wrote: > > 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.
When sending a message through AMQP doesn't the client know it is sending through AMQP ? If client knows it ideally it should pass some thing to addressing handlers to modify the reply to header. My questing is how the AMQP transport get to know about the dynamically generated destinations. When the message hit the transport is it sending some messages to the receiver prior to sending the SOAP. If that is the case the easiest thing we can do is modifying the om_tree. > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
