On 3/30/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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?
+1 to removing that. 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?
Sounds wrong to me. 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.
Would we just want to rerun the interceptor after the logical handlers then? (I don't really see any other solutions, but thats just me) Regards, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
