On Thursday 15 January 2009 4:02:46 pm Jaroslav Libak wrote:
> Doug Daniels schrieb:
> >> 2)  Certain settings on the http conduit.   The conduit is per port, so
> >> anything that the conduit manipulates would not be safe.   The main one
> >> is sessions.   The session cookie is handled in the conduit.    Thus,
> >> the port is associated with a single session (if session is turned on). 
> >>   Similarly, if you change the TLS settings, those would reflect across
> >> all the threads.
> >>
> >> Basically, for the most part, you can create a single port and use it
> >> for MOST use cases.
>
> This should be clearly documented. There should be an option in XML to
> configure "thread.local.request.context" to true. Are you sure that JAX-WS
> mandates that changes to getRequestContext() also affect other future
> invocations? If it is really true, I would even say this is a bug in JAX-WS
> standard. The function is named getRequestContext(), leading you to think
> you get something per request, but its not true!

Yea.  I'm sure.  We originally made the CXF RequestContexts a thread local and 
there was no way to get the TCK's passing.   Upon talking to Sun, it's 
definitely NOT a thread local.    Basically, its designed so that in an J2EE 
container, a Proxy can be configured (deployment descriptor stuff injected 
into context) and injected into a bean (@WebServiceRef) and then usable on 
any thread that calls that bean.   That requires the request context to not 
be thread local.   

Anyway, for JAX-WS 2.2, there has been a request to "clarify" the situation 
and the current "clarification" is that not only are the proxies non-thread 
safe, but the Service objects aren't required to be either. 


> Another setting that I think is not thread safe, is configuring http
> conduit, to use/not use TLS on the fly for every call. This is a serious
> limitation of Apache CXF, as one cannot use the same client for http and
> https, with some addresses using http, others https. I already had to write
> a patch for HTTPConduit, to allow it work with both http and https once
> https conduit is configured (but not vice versa), simply because its needed
> and configuration options in CXF are insufficient.

Submit the patch back?



-- 
Daniel Kulp
[email protected]
http://dankulp.com/blog

Reply via email to