I'm assuming you are starting a receiver (for receiving the message with the replyTo). In the client side we start the receiver first. Is it possible for your receiver to generate the destination and then sender to pick the destination from there? Also we have a method in receiver to retrieve the replyTo address as well.
Setting the reply to address by client is acceptable. But as you've pointed out if this is not set by the client this should be set automatically. I think although there is a method to retrieve the replyTo address from the receiver, it is not being used internally by axis2/c. This is feature that we should support. Supun. On Fri, Nov 14, 2008 at 9:08 AM, Danushka Menikkumbura <[EMAIL PROTECTED]>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. > > 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] > > -- Software Engineer, WSO2 Inc http://wso2.org Web Services with Axis2/C http://wsaxc.blospot.com
