[
https://issues.apache.org/jira/browse/AXIOM-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15125579#comment-15125579
]
Hudson commented on AXIOM-11:
-----------------------------
SUCCESS: Integrated in axiom-trunk #2470 (See
[https://builds.apache.org/job/axiom-trunk/2470/])
Remove the legacy behavior implemented by AXIOM-11 in getChildrenWithName.
(veithen: rev 1727870)
*
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/common/OMChildrenLegacyQNameIterator.java
*
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/mixin/AxiomContainerSupport.aj
* axiom/src/site/markdown/release-notes/1.3.0.md
*
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenWithName4.java
> OMElement.getChildrenWithName(QName) breaks customers dependent on the old
> semantics
> ------------------------------------------------------------------------------------
>
> Key: AXIOM-11
> URL: https://issues.apache.org/jira/browse/AXIOM-11
> Project: Axiom
> Issue Type: Bug
> Reporter: Rich Scheuerle
> Assignee: Rich Scheuerle
> Attachments: patch.txt
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
