Yes, and the DISABLE_RESPONSE_ACK property exists to allow the RM
implementation to indicate that the ack should be avoided.
I've run into this problem with Sandesha2 over the last few days, and
I *think* the right solution is for Sandesha2 to set that property.
Are you also working with Sandesha2 or something else?
Cheers,
David
On Mon, Mar 31, 2008 at 5:59 AM, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
>
> > hi all,
> >
> > The following code segment is there with the DispatchPhase.java class.
> > if (isOneway(mepString)) {
> > Object requestResponseTransport =
> >
> > msgContext.getProperty(RequestResponseTransport.TRANSPORT_CONTROL);
> > if (requestResponseTransport != null) {
> > ((RequestResponseTransport)
> > requestResponseTransport).acknowledgeMessage(msgContext);
> > }
> > }
> >
> > Here the idea is to set the response as Accepted if the operation is
> > one way. This is correct according to the Axis2 logic.
> Yes it is correct if the message is oneway (I mean in-only) , however if
> the message is robust-in-only then what we are doing is wrong.
>
> > But this gives a problem to RM (for piggy back model).
> > There it is supposed to send a response in the back channel for inonly
> > operations as well.
> >
> > On the other hand only ServletRequestResponseTransport has done this. the
> Well I think we need to remove this RequestResponseTransport , which is
> not the way it should be. for example how can we do this with Mail
> transport ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
