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/23 22:11:56 UTC

[jira] Created: (WSCOMMONS-351) OMElement.getChildrenWithName(QName) breaks customers dependent on the old semantics

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.

[jira] Resolved: (WSCOMMONS-351) OMElement.getChildrenWithName(QName) breaks customers dependent on the old semantics

Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
     [ 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.

[jira] Updated: (WSCOMMONS-351) OMElement.getChildrenWithName(QName) breaks customers dependent on the old semantics

Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WSCOMMONS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rich Scheuerle updated WSCOMMONS-351:
-------------------------------------

    Attachment: patch.txt

Here is the patched code and new test

> 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.