axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [Axis2]Enabling SetReplyTo() ect in the InOutMepClient is Wrong!!!
Date Thu, 01 Dec 2005 02:25:43 GMT
Hi Srinath,

> 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.

The problem is we can't do that with the Options approach .. then we'd
have to go back to getFaultTo etc. being on various MEP clients and
stubs. (Recall that Options is created independently and then hooked
onto a Call or whatever MEP client.)

> 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)

Yes absolutely. That's a way for the client to have any state its
interested in sent back to it when the server replies. Reference params
are the same as cookies, but unlike in HTTP cookies these suckers work
both ways.

> 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.

Asking users to write a handler so that they can insert a reference
property is unacceptable.

> 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.

-1 for the reasons above!

> 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 :)  ).

My thinking is along the lines of "we only build the gun, you shoot it."
We can (and will) document the perils of being sloppy with the address
field of ReplyTo and FaultTo but I don't want to disallow users from
setting it because it does have its usages. So let's go with and put big
blinking warnings!

Sanjiva.



Mime
View raw message