Hi, Thanks Aki for the test :), the issue really needed it.I can change the SAAJInInterceptor so that it does not set the XMLStreamReader.class SoapMessage's content for only the fault. But if there are more classes that are programmed to use the XMLStreamReader for the fault, I think it is better if the saaj interceptor provides an alternative content like a SOAPMessage.class for these cases. Then, in the fault interceptor, the XUtils.getQName will work since it has the Envelope Node as ancestors (SOAPMessage.getSOAPPart().getSOAPEnvelope()). This is like "we provide you with exactly what you need for your interceptor (the xmlstreamreader for the fault element only in this case) but, just in case, you can have access to more resources, like SOAPMessage, if needed". This last option implies a change in the SAAJInInterceptor and in the fault one only.What do you think?Waiting for other proposals :).Regards,C.
> Date: Fri, 23 Mar 2012 15:34:15 +0100 > Subject: Re: Issue CXF-4181 > From: [email protected] > To: [email protected] > > Hi, > I attached a unit test for this problem to your jira ticket. > > I thought a quick solution is to copy all the namespace bindings from > the reader object to the root dom element but the public API does not > have an iterator to access all the bindings. So, that didn't work. > > Someone might have a simple solution. > > regards, aki > > El día 22 de marzo de 2012 23:44, Carlos Rodríguez Fernández > <[email protected]> escribió: > > > > Hello,This issue is because the Soap12FaultInInterceptor.unmarshalFault > > receives a XMLStreamReader only for the Fault element. This is because it > > is what the SAAJInInterceptor.handleMessage does with the XMLSreamReader > > content when the message is a fault.Well, I think this issue requires a lot > > of changes. These are my options:1. Let the unmarshalFault has access to > > the whole message passing a XMLStreamReader of the whole message. Will this > > change the whole "style" of how CXF interceptors processes soap messages, > > i.e. by fragments? Since cxf is dealing with XML (ns declarations can be in > > any ancestor) I don't think it is a bad idea passing the XMLStreamReader > > for the whole message, so that, interceptors are not allowed to change the > > XMLStreamReader for specific fragments.2. Having a SOAPMessage content > > always available for when an interceptor needs it. For some reason, this > > content is not presented when the Soap12FaultInInterceptor is processing > > the message.3. Leaving everything as it is and assuming that CXF needs you > > not to have any namespace declaration in Bodies or Envelope element :S. > > This is it. I'm willing to send a big patch :). > > Regards,C.
