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, "...");"
