Bug 1007922 - RTGov does not set fault field when a fault is thrown
Summary: RTGov does not set fault field when a fault is thrown
Keywords:
Status: NEW
Alias: None
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: RT Governance
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: FUTURE
Assignee: Nobody
QA Contact: Matej Melko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-13 14:53 UTC by Jiri Pechanec
Modified: 2023-05-15 19:53 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Enhancement
Embargoed:


Attachments (Terms of Use)

Description Jiri Pechanec 2013-09-13 14:53:58 UTC
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 15:20:54 UTC
@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 16:29:29 UTC
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 16:43:15 UTC
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 16:48:38 UTC
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 16:51:38 UTC
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 06:33:00 UTC
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.