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 10:37:36 GMT



> -----Original Message-----
> From: Tully, Gary [mailto:Gary.Tully@iona.com] 
> Sent: 18 April 2007 11:13
> To: cxf-dev@incubator.apache.org
> Subject: RE: Setting ENDPOINT_ADDRESS_PROPERTY property
> 
> 
> From my reading of the JAX-WS spec, section 2.4.1 (as pointed 
> to by dan), Option #3 is correct. 


Only saw Dan's mail after I replied to Jarek's original mail.

Can you quote the relevant bit of the JAX-WS spec, because I had a quick
look at the spec before starting the original thread on this and
couldn't find any explicit guidance (probably looking in the wrong place
:)


> A thread local would still 
> be used propagate the context down the interceptor chain but 
> the instance values used to initialise the thread local for 
> each request would be maintained and synchronized by the Proxy.


Well I dunno if a ThreadLocal would be any help if we changed over to
option #3, as JaxWsClientProxy.invoke() puts both the request and reply
contexts into a fresh new over-arching per-request context that's then
passed down to Client.invoke() as an explicit param. So just making a
copy of a pre-request copy of the "master" request context would seem to
suffice, as opposed to sticking this in a ThreadLocal, unless I'm
missing something.

BTW I just noticed that ClientImpl.invoke() just slaps *all* the
properties from the incoming message into the response context, and
there don't seem to be any calls to the JaxWsClientProxy or
BindingProviderImpl.populateResponseContext() methods that look like
they're intended to filter out the non-APPLICATION-scoped properties. So
this behavior would seem to contravene the spec also. 

Cheers,
Eoghan


> 
> Gary.
> 
> 
> > -----Original Message-----
> > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > Sent: 18 April 2007 10:44
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: Setting ENDPOINT_ADDRESS_PROPERTY property
> > 
> > 
> > 
> > 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/200
> > 704.mbox/%
> > 3cFA1787F64A095C4090E76EBAF8B183E071FD5C@emea-ems1.IONAGLOBAL.com%3e
> > [2]
> > http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> > 703.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