We can handle the thing that way for sure ...But at least how about getMethods for ReplyTo with address of EPR set to final. Srinath
On 11/30/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Srinath, > > if the additional addressing properties are set, we can check Options > in specific MEP clients and throw exceptions saying those should not > be set. no? > > thanks, > dims > > On 11/30/05, Srinath Perera <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > -- > Davanum Srinivas : http://wso2.com/blogs/ >
