Bug 1202701

Summary:	(6.0.x) Unexpected behavior in fault handling with doTry/doCatch in Camel service
Product:	[JBoss] JBoss Fuse Service Works 6	Reporter:	Tadayoshi Sato <tasato>
Component:	Camel	Assignee:	Nobody <nobody>
Status:	CLOSED UPSTREAM	QA Contact:	Matej Melko <mmelko>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.0.0 GA	CC:	oskutka, ppecka, soa-p-jira
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1202699	Environment:
Last Closed:	2025-02-10 03:44:17 UTC	Type:	Support Patch
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1202699
Bug Blocks:	1183067

Description Tadayoshi Sato 2015-03-17 09:12:39 UTC

+++ This bug was initially created as a clone of Bug #1202699 +++

Platform BZ for https://issues.apache.org/jira/browse/CAMEL-8476

We have two Camel routes with doTry/doCatch for the entire route and a target SOAP endpoint that can throw SOAP faults. When the second Camel route receives a SOAP fault, the fault gets through the doTry/doCatch for both routes as they don't set handleFault=true flag. In the first route, however, the SOAP fault is just processed as state OK despite our expectation that it should be handled as FAULT.

Furthermore, if we add any arbitrary processor (e.g. <log message="xxx"/>) after the end of doTry in the second route, then surprisingly we get an expected behaviour. That is, the fault is handled as state FAULT in the first route as well.

See CAMEL-8476 for the explanation on why this behaviour happens.

Attached please find the reproducer project that is based on the 'camel-soap-proxy' quickstart. Run 'mvn test' to observe what is outlined above.

Comment 7 Red Hat Bugzilla 2025-02-10 03:44:17 UTC

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.