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
