axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <hemap...@gmail.com>
Subject Re: [Axis2]Enabling SetReplyTo() ect in the InOutMepClient is Wrong!!!
Date Wed, 30 Nov 2005 13:01:02 GMT
1) how about get methods for FaultTo and ReplyTo ect so that users can
edit the EPR but make the address of the EPR final. Becouse once the
user set a different ReplyTo address we should not start a listener
and effectivly he is doing a one way.

2) Do we have a real use case where the user want to set referance
properties of Message when it is
a) In-Out and
b)Axis2 Handles the messaging
c) It is not Policy decision (In case it should done by a handler)

Only thing I can think is user want the response to have a Header that
Axis2 do not know about. In that case he can add a Handler and do
that. Using referance property *unrelated to policy* is not a common
case I guss.

How about
a) remove the set methods
b) If ever someone ask to add a referance property via a ClientAPI,
(where is common enough senario where asking him to add a handler is
bad) lets add get methods.

I am fighting for this becouse once user set a replyTo with a
different address it become In-Only in client point of view. (we
should not start a listener) in which case he should be using
In-OnlyMEPClient. If we need a one guy who do everthing lets get rid
of the In-Only Mep client have a one MEPCleint for all. By letting
user change the ReplyTo address we make the InOutMEPcleint a
InOnlyMEPClient and breaking major archtectural principal on the
initial decision ( at least I see it that way :)  ).

Thanks
Srinath



On 11/30/05, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> I disagree with removing setReplyTo, setFaultTo etc. from Options. This
> was not a mistake; it was put there by design!
>
> Yes I know those are risky if they're used indiscriminately but they are
> needed. For example, its quite reasonable to want to set some reference
> properties on the ReplyTo EPR that I'm going to send you so that you
> will echo them back to me. I may want to set different ref props for the
> FaultTo EPR.
>
> How do you do that? One option is to have multiple methods like
> addReplyToReferenceProperty, addFaultToReferenceProperty etc.. That's
> ugly and then you'd have to do that for other part of those EPRs as
> well: setReplyToMetadata etc.. Doing that will result in a ton of
> methods being added to Options.
>
> The approach of allowing the user to create a ReplyTo etc. configured
> the way they want and then pushing it into Options (using setReplyTo) is
> a much better way!
>
> Yes of course that is dangerous *if* you set the address property of the
> ReplyTo (etc.) EPR. However everything else is fair game. So we need to
> carefully document that behavior: you the user should only set the
> address property of ReplyTo & FaultTo iff you know what you're doing
> (say because you want to route the messages thru a tcpmon instance). If
> its not set, we will put the right thing there but if its set we'll let
> it be.
>
> Sanjiva.
>
> On Tue, 2005-11-29 at 22:06 -0500, Srinath Perera wrote:
> > There are 2 way to do this
> > 1) If no simpleAxis server started, Axis2 do not register callback
> > service and we handle them ourselves use InOnlyMEPCleint
> >
> > 2) If Axis2 register a call back service, We might want to let the
> > user change the location of the Listener via the configuration.  We
> > are changing the listener for all messages not changing the replyTo
> > per message. This can be achived by registering a servlet transport
> > listener that start nothing. So the replyTo address will change for
> > that transport. This is configuration adjusment .. not a message level
> > adjesment
> >
> > Srinath
> >
> > On 11/29/05, jaliya@opensource.lk <jaliya@opensource.lk> wrote:
> > > Hi All,
> > >
> > > There is a problem if we remove these methods completely.
> > >
> > > Say a Web service (say A)is calling another Web service (say B) and now
> > > since A is inside a container it may not need to start SimpleAxisServer
> > > and will use one of the service deployed in the container as the ReplyTo
> > > address. We need to allow user to set this at this case.
> > >
> > > Thanks,
> > >
> > > Jaliya
> > >
> > > ----- Original Message -----
> > > From: "Srinath Perera" <hemapani@gmail.com>
> > > To: <axis-dev@ws.apache.org>
> > > Sent: Tuesday, Novem ber 29, 2005 9:11 PM
> > > Subject: [Axis2]Enabling SetReplyTo() ect in the InOutMepClient is Wrong!!!
> > >
> > >
> > > Hi All;
> > > In the current code the WS-A properties (ReplyTo, Related to ect) has
> > > been moved to MEPClient enabling them to all MEPClients.  But having
> > > the method in the InOutMEPClient is wrong!
> > >
> > > When user uses InOutMEPClient Axis2 take care of the messaging for him
> > > (start listeners ect.) To do so Axis2 control the WS-A properties. If
> > > we let the user set replyTo in the InOutMepClient, our listener will
> > > wait for ever for the response that is not going to come. Some goes
> > > for most of the other properties.
> > >
> > > Only OneWay MEPClient allowed to change addressing propeties (WSA-To
> > > is special), Non other is allowed to do it.
> > >
> > > So shall we change it back?
> > > Srinath
> > >
> > >
>
>

Mime
View raw message