You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2006/12/01 19:25:13 UTC

Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a request message.

Brian De Pradine wrote:
> 
>>
>> I agree with you about your claim on invalid messages being sent by
>> Axis2, if that is happening now. If that is the case, we need to fix it
>> in the sending logic and not in dispatchers or message context.
> 
> The issue here is not with the sending logic, but with the inbound
> processing logic. The WS-addressing final inbound handler must be able
> to understand that the absence of a was:To header, in a message that
> includes other mandatory ws-addressing headers, is semantically
> equivalent to the presence of the header,
> <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>. Once
> this logic is available then the handler will be spec compliant, and we
> will be able to add the capability to omit optional headers.

messageContext.to will always be either of transport URL or the value of
wsa:To address. If you want to check the presence of a wsa:To header,
then you need to look it in the envelope and not in the message contecxt.

> As an alternative, there is an existing property called
> org.apache.axis2.Constants.Configuration.TRANSPORT_IN_URL that already
> holds the inbound transport URL. If some code wants to use the transport
> URL then maybe we should consider stipulating that the code must always
> use this property to perform the lookup?

On the other way round, if some one wants to look at the addressing To
value set it as a property to message context or look in envelope.
Presence of the above TRANSPORT_IN_URL is not a must.
But presence of messagecontext.to is a must.

-- Chinthaka



Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a request message.

Posted by Brian De Pradine <PR...@uk.ibm.com>.
Hi Eran,

My response is below.

Cheers

Brian DePradine
Web Services Development
IBM Hursley
External  +44 (0) 1962 816319         Internal 246319

If you can't find the time to do it right the first time, where will you 
find the time to do it again?


Eran Chinthaka <ch...@opensource.lk> wrote on 01/12/2006 18:25:13:

> > As an alternative, there is an existing property called
> > org.apache.axis2.Constants.Configuration.TRANSPORT_IN_URL that already
> > holds the inbound transport URL. If some code wants to use the 
transport
> > URL then maybe we should consider stipulating that the code must 
always
> > use this property to perform the lookup?
> 
> On the other way round, if some one wants to look at the addressing To
> value set it as a property to message context or look in envelope.
> Presence of the above TRANSPORT_IN_URL is not a must.
> But presence of messagecontext.to is a must.

Yes this is also an alternative, I will consider if i can make this work 
for me.