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 davanum@gmail.com designates
 64.233.162.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=JaiqDtIRjTmOGBK+ZGaPQ8iPyRKX4QgDcaEHoZZQ6pVIfrpmp1JgmZtVXjCkMbl6QxvC7D83WQX0V9iA+fUbS2MbBP0ruaSbWmZKe/Az8lCGDvdH9qQVLHftiI4uiNN2EBIjkctyq3mvD4jFe8aCqjmLmhpqbiHA9mxQVvLgOGU=
Message-ID: <19e0530f0604181146m42f446a5l72a8c9f2298f4d5c@mail.gmail.com>
Date: Tue, 18 Apr 2006 14:46:21 -0400
From: "Davanum Srinivas" <davanum@gmail.com>
Reply-To: dims@apache.org
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Proposal: WS-Addressing RelatesTo API change
In-Reply-To: 
 <OF93A4141E.9A2B98E8-ON80257154.005A8116-80257154.005B1533@uk.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <1145376363.7959.4.camel@localhost.localdomain>
	 <OF93A4141E.9A2B98E8-ON80257154.005A8116-80257154.005B1533@uk.ibm.com>

Looks good to me. do we similarly keep the setRelatesTo? and what does
that mean?

thanks,
dims

On 4/18/06, David Illsley <david.illsley@uk.ibm.com> wrote:
> Yep, looks like we had a hole in the test suite :-( not sure how to test
> it in an interoperable way though...
>
> It's the end of the day here and I can't do anything tonight so I'll do i=
t
> in the morning unless anyone beats me to it ;-)
>
> RelatesTo in the W3C version is a pair of URIs, (no QNames left AFAIK) an=
d
> there is an org.apache.axis2.addressing.RelatesTo class which it's
> probably an idea to retain use of?
>
> So how about:
>   addRelatesTo(RelatesTo relatesTo)
>   RelatesTo getRelatesTo(String relationshipType) (default in W3C version
> is http://www.w3.org/2005/08/addressing/reply )
> and leave
>   RelatesTo getRelatesTo() to be a synonym of getRelatesTo("
> http://www.w3.org/2005/08/addressing/reply") as you suggested?
>
> Cheers,
> David
>
> Sanjiva Weerawarana <sanjiva@opensource.lk> wrote on 04/18/2006 05:06:03
> PM:
>
> > Ouch, this looks like a big missing hole. Hmmm the WS-Addr test suite i=
s
> > missing a serious test it seems!
> >
> > I don't like to introduce Set .. how about just remove get/setRelatesTo
> > and replace it with:
> >
> > addRelatesTo (QName relationship, String messageID)
> > String getRelatesTo (QName relationship)
> >
> > I'm actually ok with keeping "String getRelatesTo()" and have it return
> > the default relationship ID .. IIRC that was wsa:Reponse right?
> >
> > Can you do this like today so that it can get into RC2? Its critical to
> > do it ASAP!
> >
> > Sanjiva.
> >
> > On Tue, 2006-04-18 at 10:34 +0100, David Illsley wrote:
> > > Hi all,
> > >
> > > I've just opened a Jira [1] that says:
> > >
> > > The WS-Addressing spec defines the RelatesTo element as:
> > >
> > > /wsa:RelatesTo
> > >
> > >     This OPTIONAL (repeating) element information item contributes on=
e
>
> > > abstract [relationship] property value, in the form of an (IRI, IRI)
> pair.
> > > The content of this element (of type xs:anyURI) conveys the [message
> id]
> > > of the related message.
> > >
> > > The relevant APIs however only provide access to a single RelatesTo
> e.g.
> > > Options.getRelatesTo(), Options.setRelatesTo(),
> > > MessageContext.getRelatesTo(), MessageContext.setRelatesTo(). Because
> of
> > > this the AddressingInHandler extracts all present RelatesTo elements
> and
> > > calls options.setRelatesTo() for each which means that only the last
> > > RelatesTo element to be processed will be available via the API. Whil=
e
>
> > > Axis2 clients cannot add multiple RelatesTo, other implementations ma=
y
> or
> > > specifications require may multiple relationships thus this is a
> potential
> > > interoperability problem.
> > >
> > >
> > > I intend to provide a patch for this and my proposed solution is:
> > > 1. Addition of: java.util.Set getRelationships() and and void
> > > setRelationships(java.util.Set) to Options and MessageContext
> > >         get/setRelatesTos is really clumsy and the abstract property
> name
> > > in the spec is Relationship so this seems like a good name
> > > 2. Deprecation/Removal of getRelatesTo and setRelatesTo from Options
> and
> > > MessageContext
> > >         At this point just before 1.0 I think there are 3 options to
> > > support this:
> > >           a. Implement this new API and remove get/setRelatesTo befor=
e
> 1.0
> > >           b. implement this new API before 1.0 and leave
> get/setRelatesTo
> > > marked as already deprecated with Javadoc explanation
> > >           c. Leave this until after 1.0 and deprecate(with support)
> > > get/setRelatesTo in the future
> > > 3. Removal of incorrect checkDuplicateHeaders() check for RelatesTo i=
n
>
> > > AddressingInHandler
> > > 4. Modify AddressingInHandler and AddressingOutHandler to
> > > populate/serialise multiple RelatesTo elements
> > >
> > > I'm aware of how undesirable API changes are at this point but though=
t
> it
> > > better to bring up now than next week :-)
> > >
> > > What do people think of the above?
> > > Thanks,
> > > David
> > >
> > > [1] http://issues.apache.org/jira/browse/AXIS2-585
> >
>
>


--
Davanum Srinivas : http://wso2.com/blogs/