Derby
  1. Derby
  2. DERBY-3148

IllegalArgumentException: Malformed \uxxxx encoding while trying to find Xalan version running tests via ant

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.4.1.3
    • Fix Version/s: 10.4.1.3
    • Component/s: Test
    • Labels:
      None
    • Environment:
      ant 1.7.0
      IBM JVM 1.5
      Windows XP

      Description

      Following stack trace after executing:

      ant -propertyfile ant.properties junit-all-codeline-jars

      [junit] Unexpected exception while trying to find Xalan version:
      [junit] java.lang.IllegalArgumentException: Malformed \uxxxx encoding.
      [junit] at java.util.Properties.loadConvert(Properties.java:531)
      [junit] at java.util.Properties.load(Properties.java:370)
      [junit] at org.apache.derbyTesting.junit.XML.checkXalanVersion(XML.java:
      329)
      [junit] at org.apache.derbyTesting.junit.XML.<clinit>(XML.java:116)

      1. d3148_v2.patch
        2 kB
        A B
      2. d3148_v1.patch
        2 kB
        A B

        Activity

        Hide
        Daniel John Debrunner added a comment -

        The issue is that org.apache.derbyTesting.junit.XML.checkXalanVersion() assumes that

        org.apache.xalan.xslt.EnvironmentCheck.checkEnvironment()

        writes its output in a format that the java.util.Properties.load() will support and it doesn't. Its javadoc says a format similar to the Properties file format.

        I tried changing the code to ensure the output encoding was ISO-8859-1 (rather than the platform default by doing this in checkXalanVersion() but it makes no difference.

        PrintWriter pW = new PrintWriter(
        new OutputStreamWriter(bos, "ISO-8859-1"));

        I'm seeing a failure because my classpath (on windows) has elements which include '\utils' which Properties.load is trying to interpret as a unicode escape sequence (\uxxxx).

        Show
        Daniel John Debrunner added a comment - The issue is that org.apache.derbyTesting.junit.XML.checkXalanVersion() assumes that org.apache.xalan.xslt.EnvironmentCheck.checkEnvironment() writes its output in a format that the java.util.Properties.load() will support and it doesn't. Its javadoc says a format similar to the Properties file format. I tried changing the code to ensure the output encoding was ISO-8859-1 (rather than the platform default by doing this in checkXalanVersion() but it makes no difference. PrintWriter pW = new PrintWriter( new OutputStreamWriter(bos, "ISO-8859-1")); I'm seeing a failure because my classpath (on windows) has elements which include '\utils' which Properties.load is trying to interpret as a unicode escape sequence (\uxxxx).
        Hide
        A B added a comment -

        Attaching a simple patch which moves away from parsing the EnvironmentCheck output as Properties and instead just does a plain old string search for the line containing the target property. This seems to have solved the problem...

        Is this too naive of a solution?

        Show
        A B added a comment - Attaching a simple patch which moves away from parsing the EnvironmentCheck output as Properties and instead just does a plain old string search for the line containing the target property. This seems to have solved the problem... Is this too naive of a solution?
        Hide
        A B added a comment -

        Actually, I guess it is too naive. If the string "version.xalan2_2" shows up in the classpath, that'll fail, too.

        Show
        A B added a comment - Actually, I guess it is too naive. If the string "version.xalan2_2" shows up in the classpath, that'll fail, too.
        Hide
        Daniel John Debrunner added a comment -

        With the patch the byte array is written using the default encoding of the platform, and then read using ISO-8859-1.
        Whichever encoding is used, it needs to be consistent on read and write.

        Show
        Daniel John Debrunner added a comment - With the patch the byte array is written using the default encoding of the platform, and then read using ISO-8859-1. Whichever encoding is used, it needs to be consistent on read and write.
        Hide
        Daniel John Debrunner added a comment -

        maybe checking for indexOf("version.xalan2_2=") [note the equals] would be safer?

        Show
        Daniel John Debrunner added a comment - maybe checking for indexOf("version.xalan2_2=") [note the equals] would be safer?
        Hide
        A B added a comment -

        Thank you for the feedback, Dan. I'm attaching a _v2 patch that incorporates your suggestions. There is still a chance for failure if the a user has "version.xalan2_2=" in his/her classpath, but this is hopefully an improvement over the current behavior...

        Show
        A B added a comment - Thank you for the feedback, Dan. I'm attaching a _v2 patch that incorporates your suggestions. There is still a chance for failure if the a user has "version.xalan2_2=" in his/her classpath, but this is hopefully an improvement over the current behavior...
        Hide
        Daniel John Debrunner added a comment -

        Patch worked for me.

        Show
        Daniel John Debrunner added a comment - Patch worked for me.
        Hide
        A B added a comment -

        Thanks for verifying the patch, Dan.

        I ran suites.All as a sanity check on my Winows laptop and the only two failures are known issues. So committed the _v2 patch with svn # 588698:

        URL: http://svn.apache.org/viewvc?rev=588698&view=rev

        And I'm marking the issue as RESOLVED in trunk.

        Show
        A B added a comment - Thanks for verifying the patch, Dan. I ran suites.All as a sanity check on my Winows laptop and the only two failures are known issues. So committed the _v2 patch with svn # 588698: URL: http://svn.apache.org/viewvc?rev=588698&view=rev And I'm marking the issue as RESOLVED in trunk.

          People

          • Assignee:
            A B
            Reporter:
            Daniel John Debrunner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development