> -----Original Message----- > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > Sent: 30 March 2007 15:38 > To: [email protected] > Subject: RE: Why does ClientImpl.invoke() override the > EndpointInfo address? > > > > > -----Original Message----- > > From: Andrea Smyth [mailto:[EMAIL PROTECTED] > > Sent: 30 March 2007 14:31 > > To: [email protected] > > 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, "...");" > > > > > > > > > > >
