You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Alessio Soldano <as...@redhat.com> on 2012/05/04 11:36:44 UTC

JAX-WS ws providers and W3CDOMStreamWriter

Hi,
I've recently come across a Service.Mode.MESSAGE JAXWS web service
provider that was causing the following exception to be thrown when
sending responses:

org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to
insert a node where it is not permitted.
	at
org.apache.xerces.dom.CoreDocumentImpl.insertBefore(CoreDocumentImpl.java:385)
	at org.apache.xerces.dom.NodeImpl.appendChild(NodeImpl.java:236)
	at
com.sun.xml.messaging.saaj.soap.SOAPPartImpl.appendChild(SOAPPartImpl.java:492)
	at
org.apache.cxf.staxutils.W3CDOMStreamWriter.setChild(W3CDOMStreamWriter.java:119)
	at
org.apache.cxf.staxutils.W3CDOMStreamWriter.newChild(W3CDOMStreamWriter.java:109)
	at
org.apache.cxf.staxutils.W3CDOMStreamWriter.writeStartElement(W3CDOMStreamWriter.java:137)
	at
org.apache.cxf.staxutils.OverlayW3CDOMStreamWriter.writeStartElement(OverlayW3CDOMStreamWriter.java:131)
	at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:122)
	at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:81)
	at
...

The provider impl creates a SOAPMessage instance for the response from
scratch (using MessageFactory.newInstance().createMessage()) and then
adds contents to it.
After some debugging I figured out the exception above is thrown only
when the request was a SOAP 1.2 one, while the response was created
using a SOAP 1.1 MessageFactory impl.
While of course the ws provider impl is to be fixed to match the SOAP
version of the request when preparing the response, I wonder if this
could be also considered a CXF bug.
The
org.apache.cxf.staxutils.OverlayW3CDOMStreamWriter::writeStartElement(String
prefix, String local, String namespace) method is invoked to start the
DOM->Stax processing. I'm using CXF 2.5.3; there's a while loop in that
method that calls setChild((Element)nd2, *false*) on the
W3CDOMStreamWriter if the message current node (document root element
initially) matches the specified namespace. When a different soap
version is used for the SOAPMessage to be used for response, the above
check fails and the flow goes into super.writeStartElement(prefix,
local, namespace) (ie. in W3CDOMStreamWriter) which ends up trying to
replace the document root, which in turn causes the exception above. Is
this all "fine"?
Thanks
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss

Re: JAX-WS ws providers and W3CDOMStreamWriter

Posted by Daniel Kulp <dk...@apache.org>.
Hmm....

I can see two possible "fixes" for this.

1) Don't allow this at all.  In MessageModeOutInterceptor.doSoap, if the 
namespace doesn't match the expected SOAP version, throw and exception that 
is a bit more descriptive than "HIERARCHY_REQUEST_ERR".

or 

2) Remap the SoapVersion on the message - in 
MessageModeOutInterceptor.doSoap, check the namespace and if it doesn't 
match, change the SoapVersion field on the SoapMessage to the version that 
does match.  

I'm really not sure which is the "better" fix.   Likely #2, but I'm really 
not sure.   Feel free to do whichever you feel is better.   :-)

Dan



On Friday, May 04, 2012 11:36:44 AM Alessio Soldano wrote:
> Hi,
> I've recently come across a Service.Mode.MESSAGE JAXWS web service
> provider that was causing the following exception to be thrown when
> sending responses:
> 
> org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to
> insert a node where it is not permitted.
> 	at
> org.apache.xerces.dom.CoreDocumentImpl.insertBefore(CoreDocumentImpl.java:
> 385) at org.apache.xerces.dom.NodeImpl.appendChild(NodeImpl.java:236) at
> com.sun.xml.messaging.saaj.soap.SOAPPartImpl.appendChild(SOAPPartImpl.java
> :492) at
> org.apache.cxf.staxutils.W3CDOMStreamWriter.setChild(W3CDOMStreamWriter.ja
> va:119) at
> org.apache.cxf.staxutils.W3CDOMStreamWriter.newChild(W3CDOMStreamWriter.ja
> va:109) at
> org.apache.cxf.staxutils.W3CDOMStreamWriter.writeStartElement(W3CDOMStream
> Writer.java:137) at
> org.apache.cxf.staxutils.OverlayW3CDOMStreamWriter.writeStartElement(Overl
> ayW3CDOMStreamWriter.java:131) at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelo
> peStart(SoapOutInterceptor.java:122) at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(S
> oapOutInterceptor.java:81) at
> ...
> 
> The provider impl creates a SOAPMessage instance for the response from
> scratch (using MessageFactory.newInstance().createMessage()) and then
> adds contents to it.
> After some debugging I figured out the exception above is thrown only
> when the request was a SOAP 1.2 one, while the response was created
> using a SOAP 1.1 MessageFactory impl.
> While of course the ws provider impl is to be fixed to match the SOAP
> version of the request when preparing the response, I wonder if this
> could be also considered a CXF bug.
> The
> org.apache.cxf.staxutils.OverlayW3CDOMStreamWriter::writeStartElement(Stri
> ng prefix, String local, String namespace) method is invoked to start the
> DOM->Stax processing. I'm using CXF 2.5.3; there's a while loop in that
> method that calls setChild((Element)nd2, *false*) on the
> W3CDOMStreamWriter if the message current node (document root element
> initially) matches the specified namespace. When a different soap
> version is used for the SOAPMessage to be used for response, the above
> check fails and the flow goes into super.writeStartElement(prefix,
> local, namespace) (ie. in W3CDOMStreamWriter) which ends up trying to
> replace the document root, which in turn causes the exception above. Is
> this all "fine"?
> Thanks
> Alessio
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com