| Summary: | WebService Proxy - A one-way message that throws exception should not return HTTP code 500 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 5 | Reporter: | Jiri Pechanec <jpechane> | ||||||
| Component: | Documentation, JBossESB, JBossWS | Assignee: | David Le Sage <dlesage> | ||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 5.0.0 ER2 | ||||||||
| Target Milestone: | --- | ||||||||
| Target Release: | 5.2.0 GA | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| URL: | http://jira.jboss.org/jira/browse/SOA-1590 | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-11-15 09:04:47 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
Jiri Pechanec
2009-11-11 12:05:42 UTC
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. |