Comments inline: > > > > 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?
I think it is the above, which to me, indicates that there is a copy of the context, after which a request is 'final'. And this bit: 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. Which tells me that subsequent/future requests will have different values after a modification because they will be initialised with different info. > > 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. > I am afraid I cannot speak as to the intention of the writer, only to my reading of what is written. Who was it that said, "the true writer is the reader" :-) On the non-APPLICATION scoped properties, we can go either way in the absence of a line that says "only the Application scoped properties" or "no other properties" are copied. On the other hand I guess the less copying we have to do the better until we find a use case. Gary. > > > 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 > >
