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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > > To: <[email protected]> > > > 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 > > > > > > > >
