OMElement.getChildrenWithName(QName) breaks customers dependent on the old
semantics
------------------------------------------------------------------------------------
Key: WSCOMMONS-351
URL: https://issues.apache.org/jira/browse/WSCOMMONS-351
Project: WS-Commons
Issue Type: Bug
Components: AXIOM
Reporter: Rich Scheuerle
Assignee: Rich Scheuerle
Background:
OMElement.getChildrenWithName(QName searchQName) relies on
OMChildrenQNameIterator to get the child elements that have a matching qname.
The OMChildrenQNameIterator had a "loose" interpretation of equality. If the
child element's local name matched the searchQName local name, then the child
was returned.
The OMChildrenQNameIterator semantic was changed to a proper, "strict"
interpretation. (http://svn.apache.org/viewvc?view=rev&revision=522259)
Problem:
Some customers built applications that relied on the old "loose"
interpretation. Many of these customers cannot change their applications
because they are in a shipped product. When they upgrade to the new Axiom
levels, their applications fail. (Since Axiom is close to the bottom of the
stack, it is difficult to diagnose these failures).
Solution:
I want to keep the OMChildrenQNameIterator intact. It will continue to use
the "strict" interpretation.
In OMElementImpl.getChildrenWithName, I want to use the "strict"
interpretation if a fully qualified searchQName is provided.
However, in the case where the searchQName has no namespace, I want to have
a fallback.
If there are no child elements that match the unqualified qname, then I
would like the code to fallback to the old semantic.
I feel that this tactical approach is the best compromise between the
correct "strict" semantics, but also tolerates customers that relied on the old
behavior.
I will provide a patch containing both the new code, trace, and validation
testcase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
