Well that's exactly what I was asking you, and previously the group, in the earlier threads[1],[2] on this subject, i.e. whether the address over-ride should be pre-request or permanent. Your initial response was per-request.
But in any case, a few general observations on this. First, the previous way of making the address over-ride "permanent" by slapping it in the EndpointInfo was broken because: 1. the same EndpointInfo instance could be used in other contexts 2. its inconsistent to single out the ENDPOINT_ADDRESS_PROPERTY property override to linger across requests, but not do the same for the other standard props like username, password, soapaction etc. Now the underlying reason at the code level that any property set in the request context is not re-used for the next invocation is that the ThreadLocal holding this map in the JaxWsClientProxy is (rightly or wrongly) cleared between invocations. We could change this so that only the response context is cleared, but I'm not 100% sure this is the correct thing to do. For a start, the request context is implemented in CXF as a ThreadLocal<Map<...>>, so just not clearing would only allow settings to linger across invocations from the *same thread*. I'd love to set some explicit guidance from the JAX-WS spec as to what the correct extent of request context settings should be. There are at least 3 different options we could take: 1. settings apply to a single request only (the current scenario) 2. settings apply to all future requests from the *same thread* (the effect of removing the ThreadLocal.clear() from JaxWsClientProxy.invoke()) 3. settings apply to all future requests from the *same proxy* (if the effect of making the request context Map as a normal field of JaxWsClientProxy as opposed to wrapping it in a ThreadLocal, but we'd have to be careful to handle concurrent invocations safely, i.e. make a copy of the request context before invoking) Any thoughts on which of these options users *in general* would expect? I'm thinking either #1 or #3 are the most logical. Note also the convenience of not having to reset for each request a property that you really want to linger (e.g. ENDPOINT_ADDRESS_PROPERTY in your case), should be balanced against the inconvenience of having to clear a setting that must only apply to a single request (e.g. an explicit WS-A message ID). A disadvantage of approach #3 is that it would make it difficult or even impossible to do this un-setting in a thread-safe way. /Eoghan [1] http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200704.mbox/% [EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200703.mbox/% [EMAIL PROTECTED] > -----Original Message----- > From: Jarek Gawor [mailto:[EMAIL PROTECTED] > Sent: 17 April 2007 22:14 > To: [email protected] > Subject: Setting ENDPOINT_ADDRESS_PROPERTY property > > Hi, > > Regarding https://issues.apache.org/jira/browse/CXF-414 > issue. What I actually meant and expected to see when I set > the endpoint address property on the proxy, is that the > address set will be used for all calls made using that proxy > (unless of course is re-set again). For > example: > > Greeter g = foo.getPort(Greeter.class); > (javax.xml.ws.BindingProvider)g).getRequestContext().put(javax > .xml.ws.BindingProvider.ENDPOINT_ADDRESS_PROPERTY, > "http://foo/bar";); > > // call 1 > g.helloFoo(); > > // call 2 > g.helloBar(); > > For both calls address of "http://foo/bar"; will be used. It > looks like the endpoint address property is currently lost on > the second call right now. > > Jarek >
