Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: domain of hemapani@gmail.com designates
 64.233.184.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=AnEKfqO32r9BVmGRNy8DRS13IZLCVBtkN4HPNvht8mnu3o6ZEyHaz0PkJNSvfxOZIclaStyb9qmY+hI9ClNrN7XGTSbot6RpD101l6yf+cSpm1ieC5AOhzHu81vKWq09ealaLYZ7Dkxx5fjSdtzL2f378/lnhiaKCaEIhchCJpU=
Message-ID: <f8de7ee0511300501m107ea8fcg41f0abc215dd73fc@mail.gmail.com>
Date: Wed, 30 Nov 2005 08:01:02 -0500
From: Srinath Perera <hemapani@gmail.com>
To: axis-dev@ws.apache.org
Subject: Re: [Axis2]Enabling SetReplyTo() ect in the InOutMepClient is
 Wrong!!!
In-Reply-To: <1133334158.17351.10.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <1762.149.159.3.192.1133318316.squirrel@webmail1.pair.com>
	 <f8de7ee0511291906x69995055j7694f02223e037e9@mail.gmail.com>
	 <1133334158.17351.10.camel@localhost.localdomain>

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 n=
ow
> > > since A is inside a container it may not need to start SimpleAxisServ=
er
> > > and will use one of the service deployed in the container as the Repl=
yTo
> > > 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 Wr=
ong!!!
> > >
> > >
> > > 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 hi=
m
> > > (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
> > >
> > >
>
>