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: Setting ENDPOINT_ADDRESS_PROPERTY property
Date Wed, 18 Apr 2007 09:44:02 GMT


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/%
3cFA1787F64A095C4090E76EBAF8B183E071FD5C@emea-ems1.IONAGLOBAL.com%3e
[2]
http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200703.mbox/%
3cFA1787F64A095C4090E76EBAF8B183E071FCF2@emea-ems1.IONAGLOBAL.com%3e

> -----Original Message-----
> From: Jarek Gawor [mailto:jgawor@gmail.com] 
> Sent: 17 April 2007 22:14
> To: cxf-dev@incubator.apache.org
> 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
> 

Mime
View raw message