I have come across a problem in the JBossWS/CXF (I am using 3.1.0 in AS 5.1.0.Beta1 but I
think it also affects 3.1.1 and 5.1.0.CR1). It relates to the use of WSA headers with
OneWay JaxWS based service requests.
The problem only manifests when the ReplyTo header is non-null and is not the ANONYMOUS or
NONE address. This may seem a strange situation (why should a one way message employ a
ReplyTo at all) but the case in which it occurs is real -- the OASIS interoperability
tests for Web Services transactions. The service which receives the one way request is
expected to make a subsequent one way request to a related service using the value in the
ReplyTo address as the service URL. I cannot avoid supplying ReplyTo because the spec
demands it and other implementations will expect it.
The actual problem is in the JBossWS code. At the servlet end of the CXF interceptor
chain, before executing the interceptors, the WS code calls
EndpointAssociation.setEndpoint() to stash the endpoint info into a thread local (this
occurs in CXFServletExt at line 132). The final entry in the CXF interceptor chain which
dispatches to the endpoint implementation bean calls EndpointAssociation.getEndpoint() to
retrieve this stashed endpoint info (this happens in Abstractinvoker at line 134).
Now the problem is that when CXF determines that
i) a message is OneWay
ii) it is using WSA and
iii) the ReplyTo is neither null, NONE nor ANONYMOUS
it decides to be clever. It spawns a separate thread to run the interceptor chain and
allows the servlet handler thread to return early. Of course this means that the value
stashed in the thread local is not available to AbstractInvoker which promptly falls over
with an NPE at line 135.
I don't know how to work around this.Perhaps the endpoint data could be hung off the
request rather than off the thread?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230552#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...