XalanJ2
  1. XalanJ2
  2. XALANJ-1550

Problems with XPath expression //* (incorrect result and does not function after Templates object is serialized)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.7
    • Component/s: XPath
    • Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.)
    • Labels:
      None
    • Environment:
      Operating System: Windows XP
      Platform: PC

      Description

      I'll attach a test case (XML and XSL). Run the test case once creating a
      Templates from the factory, then serialize and deserialize the Templates object
      and run again. The results are not the same. The deserialized object will not
      evaluate the //* expression properly. There may be other cases but this is the
      only one I could find.

      The issues are:

      1. Aren't descendent-or-self:: and // supposed to be identical?
      2. Even if 1 is wrong, the deserialized object fails completely.

      The results I get are:

      1: (not deserialized)
      %%tag%%
      *tag*
      ((general_FITB))
      !!tag!!

      2: (serialized and deserialized)
      %%%%
      ****
      ((general_FITB))
      !!tag!!

        Activity

        Hide
        Christine Li added a comment -

        Patch has been applied. Please verify, thanks,

        Show
        Christine Li added a comment - Patch has been applied. Please verify, thanks,
        Hide
        Brian Minchau added a comment -

        Christine Li's patch was reviewed by myself (Brian Minchau), and it looks good.

        Show
        Brian Minchau added a comment - Christine Li's patch was reviewed by myself (Brian Minchau), and it looks good.
        Hide
        Christine Li added a comment -

        Created an attachment (id=11906)
        Patch for DescendantIterator

        Show
        Christine Li added a comment - Created an attachment (id=11906) Patch for DescendantIterator
        Hide
        Christine Li added a comment -

        Hi, David

        I believe that we do have a lot of test cases for //*, and it does work fine in
        general cases. This bug is related to the serializable issue. I don't think
        that we have test cases to test the serializability in case of expression //*

        Show
        Christine Li added a comment - Hi, David I believe that we do have a lot of test cases for //*, and it does work fine in general cases. This bug is related to the serializable issue. I don't think that we have test cases to test the serializability in case of expression //*
        Hide
        David Marston added a comment -

        Test cases that have //* as the whole path: axes082, select081

        Test cases that have //* within a longer path: axes055, axes084, axes085,
        boolean058, lre006, lre008, select004, variable049

        Show
        David Marston added a comment - Test cases that have //* as the whole path: axes082, select081 Test cases that have //* within a longer path: axes055, axes084, axes085, boolean058, lre006, lre008, select004, variable049
        Hide
        Christine Li added a comment -

        Thanks for the test cases, it turns out that there is a bug in the
        DescendantIterator class. For string comparison, it is safier to use
        String.equals() method, since a new String value is created during
        deserialization. e.g.
        public final static String WILD = "*";
        String x = WILD;
        WILD == x is true in most of the case, except after deserialization.

        Should always use equals() to do string comparison

        Show
        Christine Li added a comment - Thanks for the test cases, it turns out that there is a bug in the DescendantIterator class. For string comparison, it is safier to use String.equals() method, since a new String value is created during deserialization. e.g. public final static String WILD = "*"; String x = WILD; WILD == x is true in most of the case, except after deserialization. Should always use equals() to do string comparison
        Hide
        Kahli Burke added a comment -

        Issue 1 has been fixed, however the deserialized template still returns incorrect results, see attached jar
        with test case class

        Show
        Kahli Burke added a comment - Issue 1 has been fixed, however the deserialized template still returns incorrect results, see attached jar with test case class
        Hide
        Kahli Burke added a comment -

        Created an attachment (id=11881)
        Jar file with test case, do java -cp [include proper xalan/xerces libs] -jar testxml.jar

        Show
        Kahli Burke added a comment - Created an attachment (id=11881) Jar file with test case, do java -cp [include proper xalan/xerces libs] -jar testxml.jar
        Hide
        Christine Li added a comment -

        Please test with the latest Xalan2.6.0, I got the same result in both scenarios.

        Show
        Christine Li added a comment - Please test with the latest Xalan2.6.0, I got the same result in both scenarios.
        Hide
        david_marston added a comment -

        Per XPath 2.5, //* is short for
        /descendant-or-self::node()/child::*
        which should be the same as
        //descendant-or-self::*
        (all element nodes in the tree)

        But your question 1 is incomplete, since you didn't specify * vs. node().
        Nevertheless, this looks like a bug.

        Show
        david_marston added a comment - Per XPath 2.5, //* is short for /descendant-or-self::node()/child::* which should be the same as //descendant-or-self::* (all element nodes in the tree) But your question 1 is incomplete, since you didn't specify * vs. node(). Nevertheless, this looks like a bug.
        Hide
        Kahli Burke added a comment -

        Created an attachment (id=6639)
        Test case

        Show
        Kahli Burke added a comment - Created an attachment (id=6639) Test case

          People

          • Assignee:
            Unassigned
            Reporter:
            Kahli Burke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development