Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of andrea.smyth@iona.com
 designates 62.221.12.33 as permitted sender)
Message-ID: <460D111F.1000604@iona.com>
Date: Fri, 30 Mar 2007 14:31:11 +0100
From: Andrea Smyth <andrea.smyth@iona.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: Why does ClientImpl.invoke() override the EndpointInfo address?
References: <FA1787F64A095C4090E76EBAF8B183E071FCF2@emea-ems1.IONAGLOBAL.com>
In-Reply-To: <FA1787F64A095C4090E76EBAF8B183E071FCF2@emea-ems1.IONAGLOBAL.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Glynn, Eoghan wrote:

>Folks,
>
>Does anyone know why ClientImpl.invoke() overrides the EndpointInfo
>address with the Message.ENDPOINT_ADDRESS property?
>
>This has the effect of making permanent any application-level overriding
>of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY. By permanent, I mean
>applying to all subsequent invocations on this proxy, not just the
>current one.
>
>This doesn't seem correct to me, as I'd expect it to be a one-shot
>setting, i.e. applying only to a single invocation. Now the JAX-WS spec
>doesn't make this explicit, but reading between the lines of say the
>following FAQ entry[1] on jax-ws.dev.java.net suggests that's the
>intention.
>
>So does anyone a) know why ClientImpl.invoke() calls
>EndpointInfo.setAddress() and/or b) object to me removing this?
>  
>
Hi Eoghan,

I'm not sure of the impact of removing the call to 
EndpointInfo.setAddress would be on the HTTPConduit:
In its constructor,  it initialises a URL with EndpointInfo.getAddress().
But from what I can see, this initialisation can be deferred, as in any 
case during send, the HTTPConduit calls into setupURL(), which 
overwrites this url with a possibly message specific one
(so the conduit's behavior w.r.t message specific properties should 
actually be correct).

EndpointInfo.getAddress() is also used by the policy interceptors - to 
match a domain expression in a PolicyAttachment against the current 
endpoint.
<wsp:PolicyAttachment>
        <wsp:AppliesTo>
            <wsa:EndpointReference>
                
<wsa:Address>http://localhost:9020/SoapContext/GreeterPort</wsa:Address>
            </wsa:EndpointReference>
        </wsp:AppliesTo>
        <wsp:Policy>....</wsp:Policy>
 </wsp:PolicyAttachment>
Basically, EndpointInfo is used as key to cache effective policies. We 
could change this to a key that is composed of EndpointInfo AND the address.

Andrea.

>When looking into this I noticed a couple of other bizzarro aspects of
>the ENDPOINT_ADDRESS mechanism as currently implemented in CXF.
>
>1. the JaxWsClientProxy ctor sets
>BindingProvider.ENDPOINT_ADDRESS_PROPERTY to the real EndpointInfo
>address in the request context. But since the request context is cleared
>between requests, this setting is only available (to logical handlers
>etc.) for the *first* invocation on the proxy. Surely that's wrong, or?
>
>2. any overriding of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY in a
>JAX-WS LogicalHandler is ignored. This is because the
>ContextPropertiesMapping..mapRequestfromJaxws2Cxf() is only called
>upfront in the JaxWsClientProxy.invoke(), but not after the JAX-WS
>handlers have been traversed. Surely that's wrong too, or?
>
>I'm open to correction from anyone with more insight into the intent of
>the JAX-WS expert group.
>
>Cheers,
>Eoghan
>
>
>[1] https://jax-ws.dev.java.net/faq/index.html
>"Q. How can I change the Web Service address dynamically for a request ?
>
>((BindingProvider)proxy).getRequestContext().put(BindingProvider.ENDPOIN
>T_ADDRESS_PROPERTY, "...");"   
>  
>