Hello
Doug Daniels schrieb:
> Thanks Daniel,
>>
>> CXF proxies ARE thread safe except for a couple of scenarios:
>>
>> 1) Use of the port.getRequestContext(). By default per JAX-WS spec, the
>> request context is per port. Thus, any settings set on that will affect
>> other threads using the proxy. You CAN do:
>> port.getRequestContext().put("thread.local.request.context", "true");
>> and future calls to getRequestContext() will use a thread local context.
>> In
>> CXF, the response context is always thread local.
>>
>> 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!
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.
Jaro
