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 it in the morning unless anyone beats me to it ;-) RelatesTo in the W3C version is a pair of URIs, (no QNames left AFAIK) and 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 <[EMAIL PROTECTED]> wrote on 04/18/2006 05:06:03 PM: > Ouch, this looks like a big missing hole. Hmmm the WS-Addr test suite is > 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 one > > 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. While > > Axis2 clients cannot add multiple RelatesTo, other implementations may 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 before 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 in > > 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 thought 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 >
