I'm on SAP NetWeaver 7.3 EHP 1 (JEE5 certified) and I've generated a Web Service skeleton for an existing WSDL. All methods in this Webservice are non-blocking and thus annotated with @Oneway. The service itself works just fine.
I also need to access an injected WebServiceContext though, and this is where the trouble starts. I can inject the context just fine, but every call to it just ends up in server-specific NPEs or ISEs. I somewhat can understand that since the non-blocking call is executed asynchronously by SAP's JAX-WS implementation. However, I tried to validate this behaviour by looking at the JAX-WS specification.
Now I'm either blind or the specification doesn't specifically say that a WebServiceContext must not be used in non-blocking web methods. In fact, in the whole of chapter 5.3 of the latest version of the spec, @Oneway is not mentioned once. The main description is
The javax.xml.ws.WebServiceContext interface makes it possible for an endpoint implementation object and potentially any other objects that share its execution context to access information pertaining to the request being served.
The result of invoking any methods on the WebServiceContext of a component outside the invocation of one of its web service methods is undefined. An implementation SHOULD throw a java.lang- .IllegalStateException if it detects such a usage.
I guess the point is the definition of "request being served". At the time of the asynchronous handling of the SOAP operation, the HTTP request has already finished. But then again, I'm not accessing the context "outside of the invocation of one if its web service methods". I'm confused...
Does any of you guys know if I should be allowed to access the WebServiceContext in a non-blocking web method? Thanks!
You're right: the spec says nothing about this limitation - it's only vaguely implied.
From the JAX-WS spec (2.2 Rev A):
The WebServiceContext is treated as an injectable resource that can be set at the time an endpoint is initialized. The WebServiceContext object will then use thread-local information to return the correct information regardless of how many threads are concurrently being used to serve requests addressed to the same endpoint object.
Should be operational over the existence of the endpoint, but only if used in the same thread that setup and stored the request contextual information into thread-local memory storage. Given that WebServiceContext is primarily MessageContext information, which is HTTP Request / Servlet Request / WSDL Operation settings, the thread-local contextual information would probably need to be populated by the thread that initially marshalls the SOAP/HTTP request, meaning that the later async processing thread does not have this info available. Just based on reading - haven't tested this combination.