axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Supun Kamburugamuva" <>
Subject Re: Is there a smarter way to solve this issue?
Date Fri, 14 Nov 2008 04:35:25 GMT
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.


On Fri, Nov 14, 2008 at 9:08 AM, 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.
> 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:
> For additional commands, e-mail:

Software Engineer, WSO2 Inc
Web Services with Axis2/C

View raw message