> -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Monday, August 29, 2011 6:18 AM > To: [email protected] > Cc: KARR, DAVID > Subject: Re: Is the "Request Context" essentially a ThreadLocal? > > On Saturday, August 27, 2011 1:01:21 AM KARR, DAVID wrote: > > > -----Original Message----- > > > From: KARR, DAVID (ATTSI) > > > Sent: Friday, August 26, 2011 2:19 PM > > > To: [email protected] > > > Subject: Is the "Request Context" essentially a ThreadLocal? > > > > > > I consider this mostly a rhetorical question, but I need to ask it > > > nevertheless. > > > > > > If your thread has a Port object, and you get the request context > from > > > that, and you have another thread referencing the same Port object, > and > > > it gets the request context, are those two request contexts always > > > going to be different objects that don't conflict with each other? > > > > > > Whatever the answer, is this answer specific to CXF, or would any > > > reasonable JAX-WS implementation do it effectively the same way? > > > > For some more background to this, I find the following statement in > the > > JAX-WS specification in section 4.2.1, "Configuration": > > > > "Modifications to the request context while previously invoked > > operations are in-progress MUST NOT affect the contents of the > message > > context for the previously invoked operations." > > > > I also notice that CXF's "BindingProviderImpl" defines > "requestContext" as > > > "java.lang.ThreadLocal<java.util.Map<java.lang.String,java.lang.Object> > >". > > You must be using a fairly old version of CXF. Hasn't been that way > for a > long time. :-) > > > > So, it's obvious that CXF has done the reasonable thing, but what > does that > > statement in the spec really mean? Is that referring to something > > unrelated? Is what CXF is doing indicated as a MUST or even a SHOULD > in > > the spec? I'm not going to claim that what CXF is doing isn't a good > > thing, I just want to understand whether I should expect OTHER > > implementations to do the same thing, and because the spec says so. > > > By default, CXF treats the response context as a ThreadLocal. > However, for > spec compliance, the default for the request context is "per proxy". > Part of > this is due to injection and configuration requirements of the spec. > Basically, the app server needs to be able to create the client on any > thread, > configure it by setting values in the request context, and inject that > into > the app and have those values be "set" for us by that proxy on any > thread. > Also per spec, if any values are set into the proxy, all other threads > should > see it. > > However, we decided that's kind of bogus so we added the ability to > flip it to > a thread local request context as well. Setting that, however, will > result > in non-portable behavior.
Interesting. I assume that "proxy" is the same as "port"? So, if we were being spec-compliant, then we should not use the request context for anything that actually varies by each request? I suppose if we really had to, we could do something bizarre like put in a map keyed by thread id and had a handler pull it off?
