Bug 1007922 - RTGov does not set fault field when a fault is thrown
RTGov does not set fault field when a fault is thrown
Status: NEW
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: RT Governance (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
Assigned To: Gary Brown
Matej Melko
Depends On:
  Show dependency treegraph
Reported: 2013-09-13 10:53 EDT by Jiri Pechanec
Modified: 2015-11-02 03:06 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Enhancement
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jiri Pechanec 2013-09-13 10:53:58 EDT
When a fault is thrown I'd expect that the fault field in the event would be filled with the exception information.

It is doable if user uses custom code in IP but this functionality should be available OOTB.
Comment 1 Gary Brown 2013-09-13 11:20:54 EDT
@Keith - when a fault response is returned by a service, currently the message does not have a fault name (e.g. as defined in a wsdl contract). Therefore in the sample swyd/rtgov app I use an information processor (which usually is used to derived identifiers) to set the fault field in the activity event explicitly.

Is there a way that this could be done efficiently without having to use the information processor approach?
Comment 2 Keith Babo 2013-09-13 12:29:29 EDT
Can you elaborate a bit on what you mean by fault "name" in this context?  The type described in the service contract for consumer and provider is available on the exchange today.  The message name from the WSDL is not something we care about from a runtime POV.
Comment 3 Gary Brown 2013-09-13 12:43:15 EDT
e.g. <wsdl:fault name="loanProcessFault" message="tns:errorMessage" />

I thought that was the case, which is why I used the information processor to set the information. Although I agree it is not information useful for the runtime, it is useful when referring back to the original contract (e.g. wsdl), so is it something that could be made available?
Comment 4 Keith Babo 2013-09-13 12:48:38 EDT
It's possible as an enhancement, but would require looking at the actual message content to identify which fault is actually being sent.  We try not to dig into the content unless specifically instructed by the user (e.g. transformation).  

The core itself isn't aware of WSDL at all actually, since the deployer takes care of parsing the WSDL into a generic contract representation.
Comment 5 Gary Brown 2013-09-13 12:51:38 EDT
Thanks Keith.

Jiri - looks like this will need to be raised as an enhancement and then we can all discuss options for next version.
Comment 6 Jiri Pechanec 2013-09-16 02:33:00 EDT
Changed to enhancement :-)

IIRC it would be nice to at least handle situation when the content is descendant of java.util.Throwable

Note You need to log in before you can comment on or make changes to this bug.