axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject Re: [Axis2] Proposal: WS-Addressing RelatesTo API change
Date Tue, 18 Apr 2006 16:06:03 GMT
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!


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]

View raw message