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 11:36:58 GMT
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
> 
> 

Mime
View raw message