Mike, I'd agree that the old code did what the javadoc says. I'm not sure, however, that that's actually a good thing to be doing. The performance of OMChildrenQNameIterator before this change was pretty poor, so much so that I've modified a fair amount of code that knows exactly what it's looking for to avoid it. It's much faster for most QoS handlers to scan all the headers once themselves, picking out any headers they might be interested in with a single pass.
Given the fact all my code now avoids it, I'm not fussed what you make it do ;-) David On 09/10/2007, Michael Rheinheimer <[EMAIL PROTECTED]> wrote: > > > Hi All, > > 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) > > Also, the comments in the old code for > OMChildrenQNameIterator.isQNamesMatch method were careful > to point out that we should not use QName.equals: > > "Cannot use the overridden equals method of QName, as one might want to get > some element just > by giving the localname, even though a matching element has a namespace uri > as well. This is > not supported in the equals method of the 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. > > See Jira: > https://issues.apache.org/jira/browse/WSCOMMONS-256 > > Thanks. > mike -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
