Commons JXPath
  1. Commons JXPath
  2. JXPATH-12

Descendant or self axis does not work correctly at root node

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2 Final
    • Fix Version/s: 1.3
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

      Description

      Given the following XML document: <root id="1234"/>
      and the XPath: //root/@id/text().

      JXPath returns null instead of "1234".

      JXPathContext context = JXPathContext.newContext(doc);
      assertEquals(value, context.selectSingleNode("//root/@id/text()"));

      The attached JUnit test highlights the problem. It seems that JXPath does not
      find the root node if it is accessed with the axis descendant-or-self.

      1. ASF.LICENSE.NOT.GRANTED--DescendantOrSelfTest.java
        0.6 kB
        Simon Raess
      2. patch.jxpath-12.txt
        3 kB
        Marcin Sarniak
      3. xpathEvalBug.zip
        1 kB
        Murty Gurajada

        Activity

        Hide
        Simon Raess added a comment -

        Created an attachment (id=17625)
        Unit test reproducing the described bug

        Show
        Simon Raess added a comment - Created an attachment (id=17625) Unit test reproducing the described bug
        Hide
        Simon Raess added a comment -

        Note, I reproduced that bug using the JDOM model. I have not checked whether it
        works in other models.

        Show
        Simon Raess added a comment - Note, I reproduced that bug using the JDOM model. I have not checked whether it works in other models.
        Hide
        Jörg Heinicke added a comment -

        Just wondering: Does an attribute have a text child node (from a pure XML POV)?

        If yes, from a JXPath POV: Might @id/text() be the problem and not the root node?

        Show
        Jörg Heinicke added a comment - Just wondering: Does an attribute have a text child node (from a pure XML POV)? If yes, from a JXPath POV: Might @id/text() be the problem and not the root node?
        Hide
        Simon Raess added a comment -

        Actually, if I'm correct: @id/text() does not make sense from the XML POV. But, the issues is not related to
        that particular XPath. It is sufficient to use //root to reproduce the problem. I'm quite confident that the
        problem is caused by a bug in JXPath (i.e. incorrect handling of // at the root of the document.

        Show
        Simon Raess added a comment - Actually, if I'm correct: @id/text() does not make sense from the XML POV. But, the issues is not related to that particular XPath. It is sufficient to use //root to reproduce the problem. I'm quite confident that the problem is caused by a bug in JXPath (i.e. incorrect handling of // at the root of the document.
        Hide
        Marcin Sarniak added a comment -

        Adding a patch proposition for this bug (patch.jxpath-12.txt).

        As written here before, bug actually appears when xpatch is like "//root".
        It appears also when a dom is inside any java structure
        For example: map.put("test", new Document(new Element("root"))); xpatch for
        "//root" would return null.

        Exactly the same bug was both for JDom and Dom; both are fixed.

        Modifies 4 files:
        main:
        JDOMNodePointer.java
        DOMNodePointer.java
        tests:
        JDOMModelTest.java
        DOMModelTest.java

        This patch is to latest version (2.2?), not to version 1.2, reported as affected here.

        Show
        Marcin Sarniak added a comment - Adding a patch proposition for this bug (patch.jxpath-12.txt). As written here before, bug actually appears when xpatch is like "//root". It appears also when a dom is inside any java structure For example: map.put("test", new Document(new Element("root"))); xpatch for "//root" would return null. Exactly the same bug was both for JDom and Dom; both are fixed. Modifies 4 files: main: JDOMNodePointer.java DOMNodePointer.java tests: JDOMModelTest.java DOMModelTest.java This patch is to latest version (2.2?), not to version 1.2, reported as affected here.
        Hide
        Simon Raess added a comment -

        I've just applied your patch to version 1.2. The reported problem is solved now.

        Show
        Simon Raess added a comment - I've just applied your patch to version 1.2. The reported problem is solved now.
        Hide
        Matt Benson added a comment -

        committed to SVN HEAD. Thanks!

        Show
        Matt Benson added a comment - committed to SVN HEAD. Thanks!
        Hide
        Murty Gurajada added a comment -

        The fix that is in JXPath 1.3 appears to solve only part of the problem. When the context node supplied to JXPath is a Document, the evaluation of the XPath correctly returns the expected data. However, if the context node is an Element, the xpath expression does not evaluate correctly. Specifically, the behavior in JXPath 1.3 does not appear to be consistent with javax.xml.xpath in Java 1.5 as well as the text in XPath 1.0 specification.

        From the Xpath specification at:

        http://www.w3.org/TR/xpath

        descendant-or-self::para selects the para element descendants of the context node and, if the context node is a para element, the context node as well

        Section '2.5 Abbreviated Syntax' clarifies with an example:

        //para selects all the para descendants of the document root and thus selects all para elements in the same document as the context node

        Please see the attached zip file (xpathEvalBug.zip) containing a package with the JUnit test org.apache.commons.jxpath.test.TestDescOrSelfEval.java that I ran in Java 1.5.

        I have used the same xml fragment used in the bug report:

        <root id='1234'/>

        The class contains 4 tests:

        1. testJXPathDescOrSelfWithDoc() throws Exception tests JXPath evaluation of a descendant-or-self ('//') expression on a Document context

        This test returns the expected data in JXPath 1.3 whereas it used to fail in JXPath 1.2.

        2. testJXPathDescOrSelfWithEl() throws Exception tests JXPath evaluation of a descendant-or-self ('//') expression on an Element context (for 'root')

        This test does not return the expected data in JXPath 1.3. It also used to fail in JXPath 1.2.

        3. testXPathDescOrSelfWithDoc() tests javax.xml.xpath evaluation of a descendant-or-self ('//') expression on a Document context

        This test returns the expected data.

        4. testXPathDescOrSelfWithEl() tests javax.xml.xpath evaluation of a descendant-or-self ('//') expression on an Element context (for 'root')

        This test returns the expected data.

        If you run the attached JUnit test in java 1.5, the javax.xml.xpath implementation returns data consistent with the text of the specification. I really want to use JXPath in my project because some tests I ran show it is much faster than javax.xml.xpath. However, this issue is preventing me from migrating to JXPath. Is it possible to fix this issue? If yes, how soon would it be available for download?

        Show
        Murty Gurajada added a comment - The fix that is in JXPath 1.3 appears to solve only part of the problem. When the context node supplied to JXPath is a Document, the evaluation of the XPath correctly returns the expected data. However, if the context node is an Element, the xpath expression does not evaluate correctly. Specifically, the behavior in JXPath 1.3 does not appear to be consistent with javax.xml.xpath in Java 1.5 as well as the text in XPath 1.0 specification. From the Xpath specification at: http://www.w3.org/TR/xpath descendant-or-self::para selects the para element descendants of the context node and, if the context node is a para element, the context node as well Section '2.5 Abbreviated Syntax' clarifies with an example: //para selects all the para descendants of the document root and thus selects all para elements in the same document as the context node Please see the attached zip file (xpathEvalBug.zip) containing a package with the JUnit test org.apache.commons.jxpath.test.TestDescOrSelfEval.java that I ran in Java 1.5. I have used the same xml fragment used in the bug report: <root id='1234'/> The class contains 4 tests: 1. testJXPathDescOrSelfWithDoc() throws Exception tests JXPath evaluation of a descendant-or-self ('//') expression on a Document context This test returns the expected data in JXPath 1.3 whereas it used to fail in JXPath 1.2. 2. testJXPathDescOrSelfWithEl() throws Exception tests JXPath evaluation of a descendant-or-self ('//') expression on an Element context (for 'root') This test does not return the expected data in JXPath 1.3. It also used to fail in JXPath 1.2. 3. testXPathDescOrSelfWithDoc() tests javax.xml.xpath evaluation of a descendant-or-self ('//') expression on a Document context This test returns the expected data. 4. testXPathDescOrSelfWithEl() tests javax.xml.xpath evaluation of a descendant-or-self ('//') expression on an Element context (for 'root') This test returns the expected data. If you run the attached JUnit test in java 1.5, the javax.xml.xpath implementation returns data consistent with the text of the specification. I really want to use JXPath in my project because some tests I ran show it is much faster than javax.xml.xpath. However, this issue is preventing me from migrating to JXPath. Is it possible to fix this issue? If yes, how soon would it be available for download?
        Hide
        Murty Gurajada added a comment -

        Attached zip file contains a package with the JUnit test org.apache.commons.jxpath.test.TestDescOrSelfEval.java that I ran in Java 1.5 to demo a bug when an Element node context is passed to evaluate an xpath expression starting with '//'

        Show
        Murty Gurajada added a comment - Attached zip file contains a package with the JUnit test org.apache.commons.jxpath.test.TestDescOrSelfEval.java that I ran in Java 1.5 to demo a bug when an Element node context is passed to evaluate an xpath expression starting with '//'

          People

          • Assignee:
            Unassigned
            Reporter:
            Simon Raess
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development