On Monday 04 February 2008, SantoshAkhilesh wrote: > So far I had an idea that request context is put in thread local but I > realized it is not. > > Why the request context is not threadlocal ? > > If I want to send multiple client requests and each request having > different JMS header using same BindingProvider instance then do I > need to synchronize the context or not ? > > I think now it needs to synchronized else it is overwritten by > subsequent calls. > > Can anyone shed a light on this.
It's a spec compliance issue that we're still trying to battle with. Gery and I are trying to come up with a workable solution. You can follow some of the thoughts at: https://issues.apache.org/jira/browse/CXF-1410 Basically, a long long time ago, we DID use a ThreadLocal, but we could not get the TCK's to pass that way. According to spec, context variables set on any thread need to be seen for all threads. The main usage of this is in J2EE land if a proxy is injected into a another service via a @WebServiceReference or similar. At @PostContruct time, the service may configure the ENDPOINT_URL or similar into the RequestContext, but that occurs on whatever thread is doing the deploy. However, later on, when that proxy is needed, its most likely being used on a different thread and if it's thread local, the ENDPOINT_URL setting is lost. Note: this is JAX-WS spec thing, note CXF. Other JAX-WS impls have the same issue. See: http://lists.jboss.org/pipermail/jbossws-dev/2007-December/001096.html http://lists.jboss.org/pipermail/jbossws-dev/2007-December/001094.html Basically, digging into it, there doesn't seem to be anyway to make the getRequestContext be threadsafe by default without breaking spec compliance. Gary and are looking into options to possibly set a property on the proxy to switch it to threadsafe mode or possibly a CXF specific getThreadLocalRequestContext() call or similar. I'd welcome your input on the above JIRA to see what you think. Thanks! -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
