Hi Dan, thanks for having a look. The failure is still there, I've just added a testcase for that, see http://svn.apache.org/viewvc?view=revision&revision=1307325
The SOAP12FaultInInterceptor::unmarshallFault is called by the SAAJInInterceptor to parse the fault; previously the reader was used for this, now the DOM tree content in the message (key Node.class) is used instead. However, that is not a valid tree with the whole message yet; afaics (in my jbossws integration test and hence in the unit test I've just added) that content is set into the ReadHeadersInInterceptor, which however uses a PartialXMLStreamReader instance that does not process the whole message. The SAAJInInterceptor creates a default SOAPFault in the message and then delegates to Soap12FaultInInterceptor for parsing the actual one. The Soap12FaultInInterceptor however uses the message that's just been created, containing the default fault, so the original fault info are lost. I'd say we need to get back using the reader for parsing the fault, but that would basically erase the changes for CXF-4181... ;-) Cheers Alessio On 03/29/2012 08:56 PM, Daniel Kulp wrote: > > 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 -- Alessio Soldano Web Service Lead, JBoss
