cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: Why does ClientImpl.invoke() override the EndpointInfo address?
Date Fri, 30 Mar 2007 13:31:11 GMT
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, "...");"   
>  
>


Mime
View raw message