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
