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. -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
