Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a request message.
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 <[EMAIL PROTECTED]> 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.
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, > http://www.w3.org/2005/08/addressing/anonymous. 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 signature.asc Description: OpenPGP digital signature
Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a request message.
Hi Eran, Please see my comments included 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 <[EMAIL PROTECTED]> wrote on 25/11/2006 15:31:18: > Hi Brian, > > Seems to be a good observation. I agree with some of them, but not all :). > > The reason behind we keeping endpoint information inside message context > has no direct connection with WS-A. All the information in message > context can be filled by anyone, starting from transport handlers, > through addressing handler till user handlers. Please do not understand > that those information are only from WS-A headers. You are correct when you say that anyone can change any of the properties of the message context, and it is this very capability that is responsible for this problem. Currently, the wsa:To message addressing property is saved in the message context using MessageContext.setTo(), which delegates to Options.setTo(). However, the HTTP transport also saves the transport URL to that same location, by also using MessageContext.setTo(). Until now, this has not been a problem as the was:To message addressing property will simply overwrite the transport URL. The change that I want to make is to simply extend this current behaviour, of overwriting the transport URL, to the situation where the wsa:To message addressing property has been omitted, and the default value for the wsa:To message addressing property must be used. > > 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, http://www.w3.org/2005/08/addressing/anonymous. 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. > > Brian De Pradine wrote: > > > > > 3) if ws-addressing is engaged, and there are ws-addressing headers in > > the message, and one of them is the wsa:To header then it will be used > > to determine the service. > > I don't think we can hard code a requirement like this in to Axis2. > Admin of Axis2 will decide the order of dispatchers and depending on > that one dispatcher will find the operation and the service. > > For example, one will use wsa:To to reach to an endpoint but some more > information in SOAP action/request URI or QName of the first child of > the body will be used inside the engine to identify the service. It wasn't my intention to suggest that this was a strict behaviour of Axis2, only that it will be the current behaviour if the administrator decides to engage WS-Addressing with Axis2. > > > > -- Chinthaka > > [attachment "signature.asc" deleted by Brian De Pradine/UK/IBM] 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?
Re: [Axis2] Defaulting behaviour when a wsa:To header is omitted from a request message.
Hi Brian, Seems to be a good observation. I agree with some of them, but not all :). The reason behind we keeping endpoint information inside message context has no direct connection with WS-A. All the information in message context can be filled by anyone, starting from transport handlers, through addressing handler till user handlers. Please do not understand that those information are only from WS-A headers. 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. Brian De Pradine wrote: > > 3) if ws-addressing is engaged, and there are ws-addressing headers in > the message, and one of them is the wsa:To header then it will be used > to determine the service. I don't think we can hard code a requirement like this in to Axis2. Admin of Axis2 will decide the order of dispatchers and depending on that one dispatcher will find the operation and the service. For example, one will use wsa:To to reach to an endpoint but some more information in SOAP action/request URI or QName of the first child of the body will be used inside the engine to identify the service. -- Chinthaka signature.asc Description: OpenPGP digital signature