[
https://issues.apache.org/jira/browse/CXF-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533931#comment-13533931
]
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: https://issues.apache.org/jira/browse/CXF-4684
> 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: http://www.atlassian.com/software/jira
