Details
Major Description
As documented in this page the request context can be made thread local (Thus, anything set there will affect requests on other threads.), but
I observed that even after having set the property thread.local.request.context it arrives sometimes that some modifications to the request context leak the thread scope, leading potentially to unpredictable behaviors.
Digging in the code I found that the reason is the following.
The class org.apache.cxf.endpoint.ClientImpl stores the request context entries in a map called currentRequestContext. After property thread.local.request.context is set to true a call to getRequestContext() triggers the creation of another map of type org.apache.cxf.endpoint.ClientImpl.EchoContext which is associated to the current thread (the mapping is kept in the requestContext map). This should guarantee the per thread isolation.
The EchoContext is initialized with the entries of the shared map, and as its name suggests modifications are echoed back to the shared map. The problem is that when accessing the request context for the first time in a thread all the modifications done on other threads do affect the current thread even after "thread.local.request.context" is set to true, due to the initialization of the thread local map with shared one.