Hi Fred,
I can't say the client proxy guarantees the thread-safety of use the
request/ response contexts.
Because the request and response contexts are the no thread-local
objects of the JaxWsClientProxy which implements the BindingProvider
interface.
I filled a Jira *CXF-470
<https://issues.apache.org/jira/browse/CXF-470>* [1] for it, and will
make it thread-safe :).
[1] https://issues.apache.org/jira/browse/CXF-470
Cheers,
Willem.
Fred Dushin wrote:
Sorry, this is another naive JAX-WS question.
The CXF documentation at http://cwiki.apache.org/CXF20DOC/developing-
a-consumer.html illustrates a pattern for implementing a CXF client.
Under the section "Setting a request context" and "Reading a response
context", the following code is presented:
{{{
// Set request context property.
java.util.Map<String, Object> requestContext =
((javax.xml.ws.BindingProvider)port).getRequestContext();
requestContext.put(ContextPropertyName, PropertyValue);
// Invoke an operation.
port.SomeOperation();
// Read response context property.
java.util.Map<String, Object> responseContext =
((javax.xml.ws.BindingProvider)port).getResponseContext();
PropertyType propValue = (PropertyType) responseContext.get
(ContextPropertyName);
}}}
My question is, in a multi-threaded application, where say the client
proxy (port, in the above example) is shared across threads, there
are presumably no guarantees about the thread-safety of the use of
the client-request or response objects, no? Or are implementations
free to "return" a context object out of thread-local storage, for
example? Does anyone know what the CXF behavior is here?
I guess what I need to know is, is the functionally correct way to
use the above pattern to wrap it in a synchronized block (thus losing
any scalability in the client)? Or is the above pattern thread-safe
(under the assumption that port may be shared across threads)?
Thanks!
-Fred
