Alessio, I wasn't really able to re-produce this. However, I did find another bizarre issue that may have caused some strange things. With the SAAJInInterceptor configured in, by using the reader to build the dom, it was duplicating the entire fault node into the dom again. Thus, two fault nodes were present in the body which is obviously problematic. I just fixed that to bypass the reader entirely in the case the DOM is already there. Can you let me know if that fixes it? If not, any chance of a small test case?
Dan On Thursday, March 29, 2012 06:04:18 PM Alessio Soldano wrote: > Hi, > I've a failure in the jbossws-cxf testsuite that seems to be related to > the fix for cxf-4181. > I'm running a client of an endpoint, which throws a runtime unchecked > exception with a given message. Instead of an exception with expected > message, the client app is getting one with the default "Fault string, > and possibly fault code, not set". > The Soap12FaultInInterceptor::unmarshallFault(SoapMessage message, > XMLStreamReader reader) used to get the fault info from the reader. With > the latest CXF-4181 changes, the DOM info are used instead if available. > Afaics in a debugger, the dom tree (inside a > com.sun.xml.internal.messaging.saaj.soap.ver1_2.SOAPPart1_2Impl in my > case) has the default Reason string, while the reader would provide the > actual Reason message the server put in the message. I've checked the > message on the wire is fine, so the problem is indeed in the way the > client processes the fault and returns it to the client app. > Does this ring any bell? Perhaps the dom tree is not ready to be used > for this fault computation when the Soap12FaultInInterceptor is executed? > > Thanks > Alessio -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
