[
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.
