You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Carlos Rodríguez Fernández <ca...@live.com> on 2012/03/22 23:44:34 UTC
Issue CXF-4181
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.
RE: Issue CXF-4181
Posted by Carlos Rodríguez Fernández <ca...@live.com>.
Hi Aki,I added something else to the test. The unmarshalFault methods is used by the SAAJInInterceptor also, and it is there when the class receives the XMLStreamReader.class content for the fault only since the SAAJInInterceptor prepares it like that for this method.
I added this: SAAJInInterceptor saajInInterceptor = new SAAJInInterceptor(); saajInInterceptor.handleMessage(m); fault2 = (SoapFault)m.getContent(Exception.class); assertNotNull(fault2); assertEquals(Soap12.getInstance().getSender(), fault2.getFaultCode()); assertEquals(new QName("http://schemas.xmlsoap.org/ws/2005/02/trust", "FailedAuthentication"), fault2.getSubCode());
The test passes successfully. I think the issue is resolved.
Regards,C.
> From: dkulp@apache.org
> To: dev@cxf.apache.org
> CC: carlosrodrifernandez@live.com
> Subject: Re: Issue CXF-4181
> Date: Fri, 23 Mar 2012 14:13:51 -0400
>
>
> 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
>
Re: Issue CXF-4181
Posted by Daniel Kulp <dk...@apache.org>.
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
RE: Issue CXF-4181
Posted by Carlos Rodríguez Fernández <ca...@live.com>.
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: elakito@googlemail.com
> To: dev@cxf.apache.org
>
> 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
> <ca...@live.com> 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.
Re: Issue CXF-4181
Posted by Aki Yoshida <el...@googlemail.com>.
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
<ca...@live.com> 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.