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 15:06:13 GMT
 

> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com] 
> Sent: 30 March 2007 15:38
> To: cxf-dev@incubator.apache.org
> Subject: RE: Why does ClientImpl.invoke() override the 
> EndpointInfo address?
> 
>  
> 
> > -----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, 


Sorry, ignore that idea, doing the Message.ENDPOINT_ADDRESS override in
ClientImpl.getConduit() would also be broken (i.e. have the unhappy
side-effect of being permanent for that proxy).


> 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(BindingProvide
> r.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