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 11:19:20 GMT


> > 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)


Thanks Gary, I had looked at that section all right and didn't really
get a sense of explicit guidance.

Is it the sentence:

"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."

that's taken to imply that since mods to the request context must not
impact on previously invoked operations, then such mods could or should
impact on future invocations?

Or is there something stronger that I'm missing?

Sorry for being a pain on this, but the reason I want to be 100% certain
of the spec's intention is that I'm thinking of the potential impact on
WS-A, where certain properties really are intended to be pre-request.


> 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.


Yep, sounds good.

 
> > 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.


I think the following snippet from the chapter & verse you quoted 

"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."

would seem to indicate that non-APPLICATION props shouldn't be copied
into the response context.

Cheers,
Eoghan


Mime
View raw message