cxf-issues mailing list archives

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


Glen Mazza commented on CXF-4684:

Hi Aki, sorry I hadn't gotten to your dev list message, and my knowledge in this area is incomplete.
 The fact that the original submitter of this bug wrote "The SOAPFault in CXF will only throw
the 'Fault occurred while processing.' message rather than the original NPE message." shows
he doesn't understand the Pen-testing 101 rule *not* to pass service-side exception bug details
back to the client.  He didn't mention anything about the JAX-WS specification, so that wasn't
his motivation.

Why is his motivation important?  Right now, he apparently feels that if you have a database
space error, somehow the SOAP client should receive a message like "Wizard RDMBS error: Table
AdminAccountName.MY_STUFF on server camel07 is full, please expand more space for it."  That's
a training issue, and once he understands that's a no-no, I suspect he would be likely going
to request a return to 'Fault occurred while processing' again, rather than defend the new
implementation based on the apparent rule in JAX-WS 10.2.2.  Very few people indeed truly
want service-side error messages propagated back to the client (incidentally, NPEs are embarrassing
for all concerned and developers don't like it when their web service stacks embarrass them
to their customers in such a manner.)

Further, "NullPointerException" is a Java-language construct, while SOAP is language-independent.
 There shouldn't be any need to return Java-language constructs to the client, as that would
incorrectly imply the SOAP client base may base logic on the fact that the SOAP service is
implemented in Java.

I'm confused a little about your statement: "But I am more concerned about some unknown user
extended runtime exception that overwrites its toString to do more than writing its class
name."  Does this new change *facilitate* that (they can override toString() now?) or *hinder*
that (now if they tried to overwrite it, the client will still get an "NPE" message)?  If
the latter, perhaps this change does more good than harm, but if the former, I would say CXF
should tighten up and not allow this, to protect systems against sloppier developers putting
too much info in their error messages back to the client.

Anyway, CXF has several masters--the WSDL, JAX-WS, JAX-RS and WS-I Basic Profile (and Basic
Security Profile) specs--and as you know, we can't serve more than one perfectly.  I believe
CXF has already tightened itself up in a few places w.r.t. the WS-I profiles, becoming invalid
as a consequence with the more-easygoing WSDL and JAX-WS specs, both of which allow more than
what WS-I does.  This would appear to be something where going the safer route rather than
strict compliance with any specific JAX-WS rule would appear justified.  I don't think this
change is vetoable but my instinct would be to revert it, because I think its going to happen
anyway (someone several months down the road will complain about CXF improperly sending internal
error messages to the client) but if you wait several months to revert you may have to deal
with backwards compatibility issues of many SOAP clients now incorrectly basing logic based
on specific Java class exceptions being returned from the web service provider.
> 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