Thanks for the discussion and suggestions, I will open a jira to track it soon.
2012/12/3 Ivan <[email protected]> > Yeah, there may other places need to considered except for the > AbstractInvoker. > > I think that the fix should go into the places where Fault instance is > created, not the places for serialization. > > Thanks. > > 2012/12/3 Aki Yoshida <[email protected]> > > > okay. > > In that case, it looks like the faultstring needs to be obtained from > > toString(). > > > > What is not 100% clear to me is whether this rule only applies to the > > service exception thrown from AbstractInvoker or any runtime exception > > thrown during the processing. > > > > Depending on this, the fix can go into AbstractInvoker or in Fault > > itself or at the faultout interceptors 's fault serialization code as > > shown in Bin's mail. > > > > > > 2012/12/2 Ivan <[email protected]>: > > > Per the Java doc for Throwable.getMessage() method, it writes that this > > > method may return null. > > > Also, as stated in the JaxWs spec 10.2.2.3, while mapping the exception > > to > > > the soap fault, the order is : > > > > > > faultstring(Reason/Text > > > 1. SOAPFaultException.getFault().getFaultString() > > > 2. Exception.getMessage() > > > 3. Exception.toString() > > > > > > I think that this is a bug in AbstractInvoker.createFault method, a > null > > > checking for getMessage() should be required. > > > > > > Thoughts ? > > > > > > 2012/11/29 Aki Yoshida <[email protected]> > > > > > >> Hi, > > >> have you tried setting the exceptionMessageCauseEnabled property? By > > >> default, the exception cause is not written out in the fault for > > >> security concerns. But you can set this property to true to change > > >> this behavior. I think this is what you are looking for, no? > > >> > > >> > > >> > > > http://cxf.apache.org/docs/debugging-and-logging.html#DebuggingandLogging-Stacktraceinfaultdetails > > >> > > >> regards, aki > > >> > > >> 2012/11/29 Bin Zhu <[email protected]>: > > >> > Hi, > > >> > > > >> > 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. > > >> > This message("Fault occurred while processing.") hides the details > of > > the > > >> > exception and will make user hard to find the root cause of the > > >> exception. > > >> > > > >> > I did some investigation and found that > > >> > 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. > > >> > > > >> > It is suggested to improve the getMessage in the SOAPFault to let it > > >> > include the"java.lang.NullPointerException" so that the user can get > > the > > >> > details of the SOAPFault. Any suggestions? Thanks. > > >> > > > > > > > > > > > > -- > > > Ivan > > > > > > -- > Ivan >
