2

The following xpath finds a node while it shouldn't. This happens with VTD-xml java 2.12 and 2.13, while v2.11 works fine.

XML: <CONTACT><ID>10</ID></CONTACT> Xpath: //CONTACT[ID='1']/ID Result:10

Java unit test:

@Test
public void testXpath() throws Exception {
    String xml = "<CONTACT><ID>10</ID></CONTACT>";
    String expression = "//CONTACT[ID='1']/ID";

    VTDGen p = new VTDGen();
    p.setDoc(xml.getBytes("UTF-8"));
    p.parse(false);
    VTDNav nav = p.getNav();
    AutoPilot pilot = new AutoPilot(nav);
    pilot.selectXPath(expression);
    int evalXPath = pilot.evalXPath();

    if (evalXPath != -1) {
        String readValue = nav.toNormalizedString(nav.getText());
        Assert.assertEquals("10", readValue);
        Assert.fail("evalXpath should have returned -1, but returned " + evalXPath);
    }
}

When running the unit test above we get:

java.lang.AssertionError: evalXpath should have returned -1, but returned 2.

Does anyone know why this happens? Is this a known bug?

I have asked the question on the forum of VTD-xml, however noticed later a post that the questions can better be asked on StackOverflow, therefore the post here.


Edit 14-11-2016

In response to the comment below, please see the following test that fails with 2.11 (while it works with 2.9, 2.12 and 2.13)

@Test
public void testXmlModifier() throws Exception {
    String xml = "<?xml version=\"1.0\" encoding=\"UTF-16\"?><CONTACT><ID>10</ID></CONTACT>";
    String expression = "//CONTACT[ID='10']";
    String replace = "<CONTACT><ID>11</ID></CONTACT>";

    VTDGen p = new VTDGen();
    p.setDoc(xml.getBytes("UTF-16"));
    p.parse(false);
    VTDNav nav = p.getNav();

    AutoPilot pilot = new AutoPilot(nav);
    pilot.selectXPath(expression);

    if (pilot.evalXPath() != -1) {
        XMLModifier xm = new XMLModifier(nav);
        xm.remove();
        xm.insertAfterElement(replace);

        /*
         * Following call results in IndexOutOfBoundsException
         *  at java.io.FileOutputStream.writeBytes(Native Method)
         *  at java.io.FileOutputStream.write(FileOutputStream.java:326)
         *  at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122)
         *  at java.io.PrintStream.write(PrintStream.java:480)
         *  at com.ximpleware.XMLModifier.output(XMLModifier.java:2068)
         */
        xm.output(System.out);
    } else {
        Assert.fail("Should have found a node by " + expression);
    }
}

So I try to find the CONTACT with ID 10 and replace it with a new CONTACT node with ID 11. However, the call to xm.output results in IndexOutOfBoundsException.

Please do note that when changing the XML above to UTF-8, the code runs fine.

Also, while the code above actually replaces the root node (since CONTACT is the root node), this issue also exists when replacing just the subnode ID. So running the test with the following expression and replace value, gives exact the same error:

String expression = "//ID[text()='10']";
String replace = "<ID>11</ID>";
user1971430
  • 77
  • 1
  • 8

1 Answers1

1

If you have been using 2.13 version of vtd-xml.. there is a new version (2.13_1) available that solves a few reported bugs...

https://sourceforge.net/projects/vtd-xml/files/vtd-xml/ximpleware_2.13_1/ximpleware-2.13.1-java.zip/download

This is a bug that has been reported and fixed... Can you check out VTDNav.java from CVS repository and do a re-build?

Here is the link to it..

http://vtd-xml.cvs.sourceforge.net/viewvc/vtd-xml/ximple-dev/com/ximpleware/VTDNav.java?revision=1.146

vtd-xml-author
  • 3,319
  • 4
  • 22
  • 30
  • Thank you very much for the quick respons, simply putting the fixed VTDNav in _com.simpleware_ package in my project did the trick! Btw, before posting this here I have searched for bug reports, but couldn't find this one anyware...where can I look next time for known bugs? – user1971430 Nov 10 '16 at 09:42
  • Do I maybe need to patch more files, since the following xpath now _finds_ the Contact with ID _10_, while it should not find anything: `//CONTACT[ID != '10']/ID` – user1971430 Nov 10 '16 at 11:18
  • Can you expand on your finding with more specifics? I am treating it as if it may be an undiscovered new bug.... – vtd-xml-author Nov 10 '16 at 19:08
  • Thanks for the comment I think I have identified a gaffe in the code... very unfortunate and got to have it fixed... – vtd-xml-author Nov 10 '16 at 21:23
  • 1
    Thanks for the reply, please let here know when this bug is fixed as well. And if you can say something about the stability of 2.13 it would be nice to know as well, for now we will keep using 2.9 (we encounter some other problems with 2.11 as well). – user1971430 Nov 11 '16 at 09:15
  • can you elaborate on the issues you encounter with 2.11? Generally speaking 2.11 is more stable than 2.9... 2.12 and 2.13 adds a lot of efficiency improvements... it should be more bug free than 2.11, except some concentrated areas.. like the one we are discussing in this thread – vtd-xml-author Nov 11 '16 at 19:44
  • Thanks for the clarification about the versions, please see the edited post for the issue with 2.11, is this a known bug as well? – user1971430 Nov 14 '16 at 10:36
  • fyi, the != and = should have been fixed... would you like the instructions to get those fixes? – vtd-xml-author Nov 19 '16 at 07:35
  • Thanks for the notification and quick fix!. I have tested 2.11 with the fix for UTF-16, and so for no issues found yet. Therefore I prefer to wait until 2.14 for these fixes, unless I find something in 2.11 not working, but then I'll let you know here. But for other people reading this you could put instructions here for a fix, if its not too complicated. – user1971430 Nov 21 '16 at 08:40
  • 1
    i will do a 2.13.1 fix instead and release pretty soon – vtd-xml-author Nov 21 '16 at 21:48