[
https://issues.apache.org/jira/browse/WSCOMMONS-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533782
]
Rich Scheuerle commented on WSCOMMONS-256:
------------------------------------------
I can take this.
I agree with Glen's suggestions for new methods and his implementation
direction. I hope to have this fixed later today.
thanks,
Rich
> OMChildrenQNameIterator too restrictive in matching QNames
> ----------------------------------------------------------
>
> Key: WSCOMMONS-256
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-256
> Project: WS-Commons
> Issue Type: Bug
> Components: AXIOM
> Reporter: Mike Rheinheimer
> Assignee: Rich Scheuerle
> Attachments: patch.txt
>
>
> I recently updated my axiom runtime, and promptly ran into a problem where I
> could not retrieve a child element I expected to be able to retrieve when
> calling OMElementImpl.getChildrenWithName. It turns out this is due to a
> change in
> org.apache.axiom.om.impl.traverse.OMChildrenQNameIterator
> was changed in rev 522259 to be quite a bit more restrictive in establishing
> matches with the QName parameter. Formerly, the code treated a null or empty
> namespace and a null or empty localname as "match any namespace" or "match
> any localname." The new code uses QName.equals, which forces a match of both
> namespace and localname, regardless of null or empty values. From the
> QName.equals javadoc:
> "Two QNames are considered equal if and only if both the Namespace
> URI and local part are equal. This method uses String.equals()
> to check equality of the Namespace URI and local part. The prefix is NOT
> used to determine equality. "
> The javadoc for OMElementImpl.getChildrenWithName. says:
> "Searches for children with a given QName and returns an iterator to
> traverse through the OMNodes. The QName can contain any combination of
> prefix, localname and URI."
> link:
> http://ws.apache.org/commons/axiom/apidocs/org/apache/axiom/om/impl/llom/OMElementImpl.html#getChildrenWithName(javax.xml.namespace.QName)
> Seems like the old code was right if I interpret that "any combination"
> statement in the javadoc correctly. If there is no objections, I'd like to
> revert the OMChildrenQNameIterator to the pre-522259 code.
> Please see patch if necessary.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
