Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <546244820.1255616191265.JavaMail.jira@brutus>
Date: Thu, 15 Oct 2009 07:16:31 -0700 (PDT)
From: "Daniel Kulp (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Commented: (CXF-2472) if exception in fault handling, throw
 fault instead of processing exception
In-Reply-To: <131902481.1255595551315.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766071#action_12766071 ] 

Daniel Kulp commented on CXF-2472:
----------------------------------


I'm not quite sure I agree with this.   If there is an XMLStreamException being thrown, that means the actual SOAP fault was not able to be transferred back to the client.   Figuring out why that occurred is usually more important than the original fault. 

We really need to log both in this case.    Most likely, the SOAP##FaultOutInterceptors would need to log something like "Could not send SOAP fault back due to " + xe.getMessage() or similar if we rethrow the original fault back.   

> if exception in fault handling, throw fault instead of processing exception
> ---------------------------------------------------------------------------
>
>                 Key: CXF-2472
>                 URL: https://issues.apache.org/jira/browse/CXF-2472
>             Project: CXF
>          Issue Type: Improvement
>          Components: Soap Binding
>    Affects Versions: 2.2.4, 2.2.5
>            Reporter: Michael Allman
>            Priority: Minor
>         Attachments: SoapFaultOutInterceptors.patch
>
>
> In Soap11FaultOutInterceptor and Soap12FaultOutInterceptor, if we encounter an XMLStreamException writing the fault, we throw a new Fault wrapping that processing exception.  Runtime exceptions are not caught, and the original fault is lost.  I've attached a patch addressing both of these issues.
> With this patch, if there's a processing exception we will see the original fault in the server logs rather than the processing exception.  From my experience, logging this fault is much more valuable than logging the processing exception.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.