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.