On Friday, March 30, 2012 11:33:42 AM Alessio Soldano wrote: > 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... ;-)
No... the code in SAAJInInterceptor is completely wrong and needs changing. Basically, it's delegating fault handing to the SOAP##FaultInInterceptor, but is then trying to reconstruct the soap:Fault element from that information. That "works" for basic cases, but by doing that, it's losing a lot of things like empty text nodes, namespace prefix declarations the order of the fault child elements, etc... all of which could affect things like XML signatures of the fault element. I'm going to look at removing that code and seeing what might be affected. Dan > > 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 -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
