cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Why does ClientImpl.invoke() override the EndpointInfo address?
Date Fri, 30 Mar 2007 14:37:44 GMT
 

> -----Original Message-----
> From: Andrea Smyth [mailto:andrea.smyth@iona.com] 
> Sent: 30 March 2007 14:31
> To: cxf-dev@incubator.apache.org
> Subject: Re: Why does ClientImpl.invoke() override the 
> EndpointInfo address?
> 
> 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).


Yep, the HTTPConduit.send() does the right thing in terms of respecting
the Message.ENDPOINT_ADDRESS override.

And you're right, the setupURL() method could be a bit tighter in the
sense of re-using the URL created upfront in the HTTPConduit ctor, in
the case where there's no overriding via the
Message.ENDPOINT_ADDRESS/PATH_INFO/QUERY_STRING props.

However, the fragility in the current scenario I think may be around the
ClientImpl.getConduit(). 

Say the override of the Message.ENDPOINT_ADDRESS is intended to change a
*completely* bogus endpoint definition, e.g. <soap:address
location="FOO"> , to something sane like "http://localhost...". This is
the scenario in the jaxws ClientServerTest I mentioned. 

If the Message.ENDPOINT_ADDRESS isn't stuffed into
EndpointInfo.setAddress() in Client.invoke(), then the getConduit() will
fail, not because the address is wrong, but more because "FOO" is a
malformed URL string.

Of course, ClientImpl.getConduit() could take cognizance of the
Message.ENDPOINT_ADDRESS override itself, but this I think would have
the limitation that the override to a sane protocol could not be done by
the application in a JAX-WS handler. That is, it have to be done upfront
via
((BindingProviderproxy).getRequestContext().put(BindingProvider.ENDPOINT
_ADDRESS_PROPERTY, "...")

Which is I guess another reason for doing just-in-time Conduit
retrieval, but that's a whole separate discussion :)

 
> 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</ws
> a: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.


Yep, that seems sensible to me.

If the application overrides the target endpoint, then I'd guess they'd
also expect the policies to be picked up from the overridden endpoint.

But the crucial question is ... at what point in the chain does the
policy magic kick in?

If its too early in the chain (e.g. before the JAX-WS LogcialHandlers
have been traversed), then we'd still be ignoring any endpoint override
that occurs in an application handler.

Cheers,
Eoghan

> 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(BindingProvi
> der.ENDPOIN
> >T_ADDRESS_PROPERTY, "...");"   
> >  
> >
> 
> 

Mime
View raw message