cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <>
Subject [jira] [Commented] (CXF-4684) SOAPFault message improvement in CXF when there is unchecked NPE
Date Mon, 17 Dec 2012 17:34:12 GMT


Aki Yoshida commented on CXF-4684:

Hi Glen,
I agree with you that there is no point in setting the faultstring with e.toString() except
under some debugging purpose and the jaxws spec shouldn't have included this rule. I expressed
my concern which you quoted "But I am more ...". The change does not facilitate nor hinder
overriding of the exception. It simply applies this faulstring rule that can lead to not only
those internal exception message being exposed as you mentioned but also to some unknown consequences
depending on how the toString of the relevant runtime exception is implemented. 

So, I am perfectly fine with optionally enabling this rule using a configuration property.
In fact, if there is a vote to take, I choose for this option. Maybe we could reuse the enableCause
thing to align its behavior with this jaxws rule under some condition. The current behavior
of enableCause thing is not practical in some situations (e.g. when cause.getMessage() is

I'll look at it again to see what we can do.
regards, aki
> SOAPFault message improvement in CXF when there is unchecked NPE
> ----------------------------------------------------------------
>                 Key: CXF-4684
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 2.6.2
>            Reporter: Bin Zhu
>            Assignee: Aki Yoshida
>         Attachments: CXF-4684.patch
> When there is unchecked NPE thrown, the SOAPFault in CXF will only throw the "Fault occurred
while processing." message rather than the original NPE message.
> Analysis:
> 1. In org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor and org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor,
> It will check fault.getMessage() :
>                 if (fault.getMessage() != null) {
>                     if (message.get("forced.faultstring") != null) {
>                         writer.writeCharacters((String) message.get("forced.faultstring"));
>                     } else {
>                         writer.writeCharacters(fault.getMessage());
>                     }
>                 } else {
>                     writer.writeCharacters("Fault occurred while processing.");
>                 }
> But for NPE, the fault.getMessage() will return null instead of the "java.lang.NullPointerException"
in the getMessage() in NPE.
> 2. 
> Fault.getMessage will return null in the NPE scenario while it's super class Throwable
will not.
> When there is NPE, the message attribute in Fault is null while the detailMessageAtrribute
is "java.lang.NullPointerException".
> Details:
> SoapFault->Fault->UncheckedException->RuntimeException->Exception->Throwable.
//  SoapFault->Fault means SoapFault class extends Fault class
> UncheckedException.getMessage:
>     public String getMessage() {
>         if (null != message) {
>             return message.toString();
>         }
>         return null;
>     }
> Throwable.getMessage:
> public String getMessage() {
> 	return detailMessage;
> }

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:

View raw message