Date of First Response: 2009-12-02 05:48:19 project_key: SOA Whe WebService proxy is used to invoke one-way web service that thros a runtime exception then the error code 500 is returned to client together with fault message. According to WS-I profile The HTTP response to a one-way operation indicates the success or failure of the transmission of the message. Based on the semantics of the different response status codes supported by the HTTP protocol, the Profile specifies that "200" and "202" are the preferred status codes that the sender should expect, signifying that the one-way message was received. A successful transmission does not indicate that the SOAP processing layer and the application logic has had a chance to validate the envelope or have committed to processing it. Only 200 or 202 codes should be returned as the message was successfully transmitted to JBossESB and code 500 should not be used to report errors at service level.
Jirka can you provide an example for kconner please
Attachment: Added: oneway_exc.zip
Link: Added: This issue depends JBESB-3035
To me, this looks to be an issue with JBossWS. The webserive operation itself is not honoring the @Oneway annotation on th webmethod. The WS container is returning the exception as thrown by the webmethod.
I'll look at the SOAPProxy code and see is there a way we can enforce this from inside the ESB.
The SOAP Proxy should be doing just that, proxying the response (whatever it is). If this is a JBossWS issue then we need to pass it over to them,
Sure... this is an issue with JBossWS, but perhaps the SOAPProxy should be able to enforce it too... what if it's proxying to something other than JBossWS?... I would have thought people would expect an ESB to be able to help them resolve issues like this. That said, it would change this into a feature request from the pov of the platform.
Ignore my last comment... they can always implement an action (following the proxy).
Added test war with @Oneway operation. Install in AS container and execute using soapUI (or whatever). You get a 500 response + operation execution details (in this case, an exception).
Attachment: Added: Quickstart_webservice_proxy_basic_ws.war
So just to reiterate... this is not a bug in the ESB. This needs to be worked out with the JBossWS guys.
Tom has shown that this issue lies with JBossWS rather than ESB
Added issue to Release Notes. Draft text reads: https://jira.jboss.org/jira/browse/SOA-1590 When the Web Service proxy is used to invoke a one-way web service, it erroneously throws a run-time exception with HTTP Code 500, which is returned to the client together with a fault message. HTTP Code 500 is invalid in these situations as only Code 200 or 202 should ever be returned as the message was successfully transmitted to the ESB.
Perhaps something like the following? When the Web Service proxy is used to invoke any method it will return the response as provided by the target webservice. In some instances the target webservice may return a response which is not valid within the invoking context. The Web Service proxy does not sanitise these responses and will pass the response back to the caller.
Candidate for documentation for SOA 5.1.0
down as documentation. If you need more information, give me a yell
PM team decided this is not a blocker for SOA 5.1.0. Darran will create a jbpapp JIRA and link together with this one.
Writer: Added: dlesage
Release Notes Docs Status: Added: Documented as Known Issue Release Notes Text: Added: https://issues.jboss.org/browse/SOA-1590 When the Web Service proxy is used to invoke any method it will return the response as provided by the target webservice. In some instances the target webservice may return a response which is not valid within the invoking context. The Web Service proxy does not sanitise these responses and will pass the response back to the caller.
Added as release note.