[
https://issues.apache.org/jira/browse/WSCOMMONS-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533403
]
Glen Daniels commented on WSCOMMONS-256:
----------------------------------------
Hi Mike!
I changed that code in the midst of a lot of fixes to be more correct and
precise in our APIs, and I think the current behavior (matching on
QName.equals()) is correct for getChildrenWithName(). If you'd like the
behavior of matching all elements with a particular namespace or a particular
local name, I'm 100% fine with adding APIs for that purpose - but I do NOT
think we should go back to a quirky overloaded behavior change based on null
values in a QName. Also, technically these days you can't actually have those
null values in QName anyway - you end up with "" (XMLConstants.NULL_NS_URI) for
ns and an IllegalArgumentException for localPart if you try, IIRC!
So what I'm suggesting is the following:
* Add getChildrenWithLocalPart(String) and/or getChildrenWithNamespace(String)
to OMElement
* Refactor OMChildrenQNameIterator into an abstract base class which has a
match() function (see SOAPHeaderImpl$HeaderIterator for something similar), and
then an implementation of match() which checks QName equality. Also make
implementations which check namespace and localPart equality, and hook those up
with getChildrenWithLocalPart(), etc. I think we might not even need separate
classes for this, but instead can use anonymous classes inside the OMElement
methods....
I'm happy to do this work (and maybe clean up the other iterators in that
package too) if it sounds good to you.
> 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
> 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]
