[esb-issues] [JBoss JIRA] (JBESB-3796) Exception handling after SyncServiceInvoker fails

[ https://issues.jboss.org/browse/JBESB-3796?page=com.atlassian.jira.plugin... ] Sato Tadayoshi commented on JBESB-3796: --------------------------------------- I find that rather the root cause should be located in ActionProcessingPipeline. I understand that the core philosophy of ActionProcessingPipeline is use the ReplyTo/FaultTo of the original request message header when it returns the normal response message or the fault message regardless of however these headers are changed during the action processing. At the innermost processPipeline(Message) method, the call info of the original request message is surely cached to 'callDetails' variable, and this cache is consistently refered to for determining the FaultTo EPR in the faultTo method when an exception occurs while processing actions. However, what's not consistent is when the error message is created by invoking Factory.createErrorMessage(...) method, which unfortunatelly refers to the original request message itself instead of the callDetails cache. To make things worse, Factory.createErrorMessage(...) returns the input message rather than a newly created error message if the input message doesn't have ReplyTo/FaultTo in its header, which is the case of this issue. That's why an ESB service doesn't return a SOAP fault but the normal result of SyncServiceInvoker to the client. Considering that the problem is in this inconsistency of ActionProcessingPipeline and the same issue can occur with any actions which manipulates the request message header to null, I think the correct fix to the issue should be modifying ActionProcessingPipeline and Factory.createErrorMessage(...). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira