[
https://issues.apache.org/jira/browse/CXF-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2033.
------------------------------
Resolution: Fixed
Fix Version/s: 2.1.5
2.0.11
> StaxUtils assumes DOM Node::appendChild(c) returns the passed-in child
> ----------------------------------------------------------------------
>
> Key: CXF-2033
> URL: https://issues.apache.org/jira/browse/CXF-2033
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.1.4
> Environment: OSX, JBoss AS5, JDK6
> Reporter: bob mcwhirter
> Assignee: Daniel Kulp
> Fix For: 2.0.11, 2.1.5
>
> Original Estimate: 0.05h
> Remaining Estimate: 0.05h
>
> StaxUtils does XML manipulation:
> http://svn.apache.org/repos/asf/cxf/trunk/common/common/src/main/java/org/apache/cxf/staxutils/StaxUtils.java
> in startElement(...) it builds a fragment and attaches it to a parent using
> appendChild(e):
> parent.appendChild(e);
> When using this with the JBoss AS5 SOAP/DOM implementation, a SOAPBody
> appending a SOAPElement will return a different object than the one
> passed-in. (In JBoss's case, you get back a SOAPBodyElement that's quite
> similar to, but distinct from, the SOAPElement you passed to
> appendChild(...)).
> The DOM spec says that appendChild(...) returns the node that was appended,
> which implies (to me, and at least 1 other JBoss developer) that it may be
> different than the one you handed in.
> This only becomes a problem when later in startElement(...), code calls
> e.getParent() to perform some logic. This fails with JBoss DOM, since the
> 'e' StaxUtils is holding was detached from its own parent, and replaced with
> a different element node.
> The fix is simply to assign the result of appendChild(e) back to e itself:
> e = (Element) parent.appendChild(e);
> This causes StaxUtils not to freak out the JBoss DOM.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
