You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Danushka Menikkumbura <da...@wso2.com> on 2008/11/14 04:43:40 UTC
Is there a smarter way to solve this issue?
Devs,
I need to modify WS-A ReplyTo with a piece of data that is available
just before sending the message out at the transport level. As far as I
can see, the only way to do this is to process the serialized SOAP
envelop at the transport level, as the SOAP envelop is built already
when the transport sender is hit.
Is there a smarter way to do this?
Danushka
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Is there a smarter way to solve this issue?
Posted by Manjula Peiris <ma...@wso2.com>.
You can change the replyTo by traversing the SOAP om_tree, before
serializing in the transport. But explain your requirement more so we
may be able to identify an alternative.
On Fri, 2008-11-14 at 08:55 +0500, Supun Kamburugamuva wrote:
> Hi,
>
> 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?
>
> Thanks,
> Supun.
>
> On Fri, Nov 14, 2008 at 8:43 AM, Danushka Menikkumbura
> <da...@wso2.com> wrote:
> Devs,
>
> I need to modify WS-A ReplyTo with a piece of data that is
> available just before sending the message out at the transport
> level. As far as I can see, the only way to do this is to
> process the serialized SOAP envelop at the transport level, as
> the SOAP envelop is built already when the transport sender is
> hit.
>
> Is there a smarter way to do this?
>
> Danushka
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> Web Services with Axis2/C http://wsaxc.blospot.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Is there a smarter way to solve this issue?
Posted by Danushka Menikkumbura <da...@wso2.com>.
> When sending a message through AMQP doesn't the client know it is
> sending through AMQP ?
>
>
It does.
> If client knows it ideally it should pass some thing to addressing
> handlers to modify the reply to header.
>
Is it a good thing to let the client programmer intervene with low-level
stuff?
> 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.
>
>
Please refer to my reply to Supun's last mail on this thread.
Thanks
Danushka
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Is there a smarter way to solve this issue?
Posted by Rajika Kumarasiri <ra...@gmail.com>.
On Fri, Nov 14, 2008 at 10:43 AM, Manjula Peiris <ma...@wso2.com> wrote:
>
> 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.
In Axis2/Java case , the JMS transport creates a temp queue and listing on
that temp queue for the response, in which the response is written back to
that temp queue in the broker.
-Rajika
> 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: axis-c-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
--
http://wso2.org/
http://llvm.org/
http://www.osdev.org/
Re: Is there a smarter way to solve this issue?
Posted by Manjula Peiris <ma...@wso2.com>.
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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Is there a smarter way to solve this issue?
Posted by Supun Kamburugamuva <su...@gmail.com>.
>
>> Well my concern is if we really want to let the client programmer
> manipulate the separate listener in dual-channel case.
>
> Ideally what the client programmer should do is just call *
>
> axis2_options_set_use_separate_listener(options, env, AXIS2_TRUE);*
>
> Don't you think so?
>
Yes I agree. But there are cases where the replyTo address doesn't represent
anything network resolvable. For example setting it to a anonymous endpoint.
In these cases we should use that method.
Supun.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
Web Services with Axis2/C http://wsaxc.blospot.com
Re: Is there a smarter way to solve this issue?
Posted by Danushka Menikkumbura <da...@wso2.com>.
Supun,
> When the destination is generated by sender, does the sender block
> waiting for the remote broker to generating the destination? If that
> is the case we can still move this destination generating logic to the
> receiver and make the sender block waiting for receiver until it
> generates the destination.
Yes. This is a good workaround. I forgot the fact that it was possible
to get the AMQP message headers to let the server know the ReplyTo
destination name. So, WS-A ReplyTo and AMQP ReplyTo together would do
the trick.
>
> Yes I agree with you about the user setting the replyTo address. That
> localhost:6060 should be configured in the axis2.xml to make that
> work. That means we are duplicating an information that we already
> have. If the user sets a replyTo address like the above, my preference
> is what ever set in the axis2.xml for transport receiver should be
> overridden by the user input.
>
Well my concern is if we really want to let the client programmer
manipulate the separate listener in dual-channel case.
Ideally what the client programmer should do is just call *
axis2_options_set_use_separate_listener(options, env, AXIS2_TRUE);*
Don't you think so?
Thanks
Danushka
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Is there a smarter way to solve this issue?
Posted by Supun Kamburugamuva <su...@gmail.com>.
When the destination is generated by sender, does the sender block waiting
for the remote broker to generating the destination? If that is the case we
can still move this destination generating logic to the receiver and make
the sender block waiting for receiver until it generates the destination.
Yes I agree with you about the user setting the replyTo address. That
localhost:6060 should be configured in the axis2.xml to make that work. That
means we are duplicating an information that we already have. If the user
sets a replyTo address like the above, my preference is what ever set in the
axis2.xml for transport receiver should be overridden by the user input.
Supun.
On Fri, Nov 14, 2008 at 9:54 AM, Danushka Menikkumbura <da...@wso2.com>wrote:
>
> Is it possible for your receiver to generate the destination and then
>> sender to pick the destination from there?
>>
> Since the transport works with a remote broker, this is not a viable
> option. Because it is not guaranteed that the listener is done with creating
> the destination by the time the sender is ready to send.
>
>> 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.
>>
> Well my gut feeling is that letting the user set something like
> http://localhost:6060/axis2/services/__ANONYMOUS_SERVICE__/__OPERATION_OUT_IN__is not that neat.
>
>> I think although there is a method to retrieve the replyTo address from
>> the receiver, it is not being used internally by axis2/c.
>>
> True.
>
>
> Danushka
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
Web Services with Axis2/C http://wsaxc.blospot.com
Re: Is there a smarter way to solve this issue?
Posted by Danushka Menikkumbura <da...@wso2.com>.
> Is it possible for your receiver to generate the destination and then
> sender to pick the destination from there?
Since the transport works with a remote broker, this is not a viable
option. Because it is not guaranteed that the listener is done with
creating the destination by the time the sender is ready to send.
> 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.
Well my gut feeling is that letting the user set something like
http://localhost:6060/axis2/services/__ANONYMOUS_SERVICE__/__OPERATION_OUT_IN__
is not that neat.
> I think although there is a method to retrieve the replyTo address
> from the receiver, it is not being used internally by axis2/c.
True.
Danushka
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Is there a smarter way to solve this issue?
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <da...@wso2.com>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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
Web Services with Axis2/C http://wsaxc.blospot.com
Re: Is there a smarter way to solve this issue?
Posted by Danushka Menikkumbura <da...@wso2.com>.
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Is there a smarter way to solve this issue?
Posted by Supun Kamburugamuva <su...@gmail.com>.
Hi,
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?
Thanks,
Supun.
On Fri, Nov 14, 2008 at 8:43 AM, Danushka Menikkumbura <da...@wso2.com>wrote:
> Devs,
>
> I need to modify WS-A ReplyTo with a piece of data that is available just
> before sending the message out at the transport level. As far as I can see,
> the only way to do this is to process the serialized SOAP envelop at the
> transport level, as the SOAP envelop is built already when the transport
> sender is hit.
>
> Is there a smarter way to do this?
>
> Danushka
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
Web Services with Axis2/C http://wsaxc.blospot.com