You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Rich Scheuerle (JIRA)" <ji...@apache.org> on 2008/05/27 16:40:39 UTC
[jira] Resolved: (WSCOMMONS-351)
OMElement.getChildrenWithName(QName) breaks customers dependent on the old
semantics
[ https://issues.apache.org/jira/browse/WSCOMMONS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rich Scheuerle resolved WSCOMMONS-351.
--------------------------------------
Resolution: Fixed
> 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
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.