cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Issue CXF-4181
Date Fri, 23 Mar 2012 18:13:51 GMT

Just committed a fix for this to trunk using Aki's unit test.   Can you and 
Aki take a quick look?

Basically, the SOAP Envelope/Body is stored on the message as a DOM node.   
Thus, when we parse the fault to the DOM, we can actually parse it right 
into the correct place in the original DOM.   All the namespaces would be 
resolvable and such at that point. 

Dan


On Thursday, March 22, 2012 03:44:34 PM Carlos Rodríguez Fernández wrote:
> 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.
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message