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