Uploaded image for project: 'Axiom'
  1. Axiom
  2. AXIOM-11

OMElement.getChildrenWithName(QName) breaks customers dependent on the old semantics

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • None
    • None
    • None

    Description

      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.

      Attachments

        1. patch.txt
          6 kB
          Rich Scheuerle

        Activity

          People

            scheu@us.ibm.com Rich Scheuerle
            scheu@us.ibm.com Rich Scheuerle
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: