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