cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tully, Gary" <Gary.Tu...@iona.com>
Subject RE: Setting ENDPOINT_ADDRESS_PROPERTY property
Date Wed, 18 Apr 2007 10:57:46 GMT
Hi, 

> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com] 
> Sent: 18 April 2007 11:38
> To: cxf-dev@incubator.apache.org
> Subject: RE: Setting ENDPOINT_ADDRESS_PROPERTY property
> 
> 
> 
> 
> > -----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
> :)
> 

Here is the relevant bit - ignore the line nos at the end unless it
helps identify a bit of the text
For discussion. (reproduced without permission for
clarification/discussion purposes only)


4.2.1 Configuration 1
Additional metadata is often required to control information exchanges,
this metadata forms the context of 2
an exchange. 3
A BindingProvider instance maintains separate contexts for the request
and response phases of a mes- 4
sage exchange with a service: 5
Request The contents of the request context are used to initialize the
message context (see section 9.4.1) 6
prior to invoking any handlers (see chapter 9) for the outbound message.
Each property within the 7
request context is copied to the message context with a scope of
HANDLER. 8
Response The contents of the message context are used to initialize the
response context after invoking any 9
handlers for an inbound message. The response context is first emptied
and then each property in the 10
message context that has a scope of APPLICATION is copied to the
response context. 11
} Conformance (Message context decoupling): Modifications to the request
context while previously in- 12
voked operations are in-progress MUST NOT affect the contents of the
message context for the previously 13
invoked operations. 14
The request and response contexts are of type
java.util.Map<String,Object> and are obtained using 15
the getRequestContext and getResponseContext methods of BindingProvider.
16
In some cases, data from the context may need to accompany information
exchanges. When this is required, 17
protocol bindings or handlers (see chapter 9) are responsible for
annotating outbound protocol data units 18
and extracting metadata from inbound protocol data units. 19
Note: An example of the latter usage: a handler in a SOAP binding might
introduce a header into a SOAP 20
request message to carry metadata from the request context and might add
metadata to the response context 21
from the contents of a header in a response SOAP message. 22


> 
> > 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.
> 
Agreed, that would be fine if it is a parameter. The idea is just that
there is a clear separation where a copy is made, after which mods to
the master copy are ignored and inline mods to the copy are contained to
the thread or to the request.

> 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. 
> 
I imagine the conformance is about the presence of the APPLICATION
Scoped properties rather than the absence of non-application ones so
this will be ok. Some intelligent being may want access to the low level
details but could only portably depend on the application ones being
present.

Gary.


> 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