Derby
  1. Derby
  2. DERBY-5069

Since Feb 7,2011 weme 6.2 Junit tests have failed to run completely with Failed to invoke suite():java.lang.reflect.InvocationTargetException

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.8.1.2
    • Component/s: Test
    • Labels:
      None
    • Issue & fix info:
      High Value Fix, Patch Available
    • Bug behavior facts:
      Regression, Regression Test Failure

      Description

      Since Feb 8, the weme 6.2 Junit tests have failed to run. The only output on the test report is:

      Failed to invoke suite():java.lang.reflect.InvocationTargetException

      Below is the list of checkins on the day it started failing. derbyall looks ok.

      SUBVERSION LOG FROM 1067846 TO 1068253:
      ------------------------------------------------------------------------
      r1068073 | rhillegas | 2011-02-07 11:34:02 -0800 (Mon, 07 Feb 2011) | 1 line

      DERBY-4869: Attempt to fix problem in tinderbox tests introduced by a previous commit today.
      ------------------------------------------------------------------------
      r1067991 | rhillegas | 2011-02-07 08:04:25 -0800 (Mon, 07 Feb 2011) | 1 line

      DERBY-4869: Always raise SQLFeatureNotSupportedException when Connection.get/setNetworkTimeout() is called.
      ------------------------------------------------------------------------
      r1067954 | rhillegas | 2011-02-07 06:54:31 -0800 (Mon, 07 Feb 2011) | 1 line

      DERBY-4869: Add JDBC 4.1 getParentLogger() method to Derby's implementations of Driver and CommonDataSource.
      ------------------------------------------------------------------------

      This should be promoted to blocker if determined to be a product regression.

      1. TestWemeLoad.java
        2 kB
        Kathey Marsden
      2. derby-5069_diff.txt
        4 kB
        Kathey Marsden

        Activity

        Gavin made changes -
        Workflow jira [ 12600022 ] Default workflow, editable Closed status [ 12802868 ]
        Knut Anders Hatlen made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Knut Anders Hatlen added a comment -

        [bulk update] Close all resolved issues that haven't been updated for more than one year.

        Show
        Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.
        Kathey Marsden made changes -
        Component/s Test [ 11413 ]
        Rick Hillegas made changes -
        Fix Version/s 10.8.1.2 [ 12316362 ]
        Fix Version/s 10.8.1.1 [ 12316356 ]
        Rick Hillegas made changes -
        Fix Version/s 10.8.1.1 [ 12316356 ]
        Fix Version/s 10.8.1.0 [ 12315561 ]
        Kathey Marsden made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 10.8.0.0 [ 12315561 ]
        Resolution Fixed [ 1 ]
        Hide
        Kathey Marsden added a comment -

        Thanks Knut for checking phoneME, I will assume that is the correct behavior then and close this issue out. Thank you too to Myrna for checking the nightlies.

        Show
        Kathey Marsden added a comment - Thanks Knut for checking phoneME, I will assume that is the correct behavior then and close this issue out. Thank you too to Myrna for checking the nightlies.
        Hide
        Myrna van Lunteren added a comment -

        Thanks Kathey for investigating and re-enabling the run for weme. The
        Saturday run looks good except for 1 failure with ibm 1.6. (I'll take
        a look).

        But looks to me like the release candidate is planned for a week from
        Monday, although release notes draft & buddy testing were planned for
        Monday.

        Myrna

        Show
        Myrna van Lunteren added a comment - Thanks Kathey for investigating and re-enabling the run for weme. The Saturday run looks good except for 1 failure with ibm 1.6. (I'll take a look). But looks to me like the release candidate is planned for a week from Monday, although release notes draft & buddy testing were planned for Monday. Myrna
        Hide
        Knut Anders Hatlen added a comment -

        The test program gives a NoClassDefFoundError on phoneME too:

        java.lang.NoClassDefFoundError: java.sql.Driver
        at java.lang.Class.loadSuperClasses(Unknown Source)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Unknown Source)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at TestWemeLoad.main(Unknown Source)
        at sun.misc.CVM.runMain(Unknown Source)

        Show
        Knut Anders Hatlen added a comment - The test program gives a NoClassDefFoundError on phoneME too: java.lang.NoClassDefFoundError: java.sql.Driver at java.lang.Class.loadSuperClasses(Unknown Source) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Unknown Source) at java.net.URLClassLoader.findClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at TestWemeLoad.main(Unknown Source) at sun.misc.CVM.runMain(Unknown Source)
        Kathey Marsden made changes -
        Attachment TestWemeLoad.java [ 12472008 ]
        Hide
        Kathey Marsden added a comment -

        It is the driver.getClass() call that prevents the class from loading with weme. If I run the attached Program TestWemeLoad.java with the driver.getClass call as attached I get the following error verifying the class.

        + c:/cygwin/ibmsvn/ntsoftware/weme6.2/bin/j9 -jcl:foun11 -DderbyTesting.serverho
        st=localhost -DderbyTesting.clienthost=localhost -Demma.active= -Xbootclasspath/
        a:c:/cygwin/ibmsvn/ntsoftware/weme6.2/lib/jdbc.jar -Dbootcp=c:/cygwin/ibmsvn/nts
        oftware/weme6.2/lib/jdbc.jar TestWemeLoad
        Exception in thread "main" java.lang.NoClassDefFoundError: java.sql.Driver
        at java.lang.J9VMInternals.verifyImpl(Native Method)
        at java.lang.J9VMInternals.verify(J9VMInternals.java:88)
        at java.lang.J9VMInternals.initialize(J9VMInternals.java:150)

        If I comment out the line
        // System.out.println(driver.getClass());

        it runs and exits gracefully with:
        Not going to run because I am J2ME

        I am curious if this is specific to WEME or if phoneME behaves the same way. I am sort of surprised even with the getClass() commented out that the class verifies with all the Driver and DriverManager references.

        Show
        Kathey Marsden added a comment - It is the driver.getClass() call that prevents the class from loading with weme. If I run the attached Program TestWemeLoad.java with the driver.getClass call as attached I get the following error verifying the class. + c:/cygwin/ibmsvn/ntsoftware/weme6.2/bin/j9 -jcl:foun11 -DderbyTesting.serverho st=localhost -DderbyTesting.clienthost=localhost -Demma.active= -Xbootclasspath/ a:c:/cygwin/ibmsvn/ntsoftware/weme6.2/lib/jdbc.jar -Dbootcp=c:/cygwin/ibmsvn/nts oftware/weme6.2/lib/jdbc.jar TestWemeLoad Exception in thread "main" java.lang.NoClassDefFoundError: java.sql.Driver at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:88) at java.lang.J9VMInternals.initialize(J9VMInternals.java:150) If I comment out the line // System.out.println(driver.getClass()); it runs and exits gracefully with: Not going to run because I am J2ME I am curious if this is specific to WEME or if phoneME behaves the same way. I am sort of surprised even with the getClass() commented out that the class verifies with all the Driver and DriverManager references.
        Hide
        Kathey Marsden added a comment -

        Thank you Lily for looking at the change. I would really like to understand when the JSR169 check needs to be in the suite vs the test after the small changes to DriverTest. I checked in the change to get the tests running again, but will leave this issue open for a little bit I try to understand that better.

        Show
        Kathey Marsden added a comment - Thank you Lily for looking at the change. I would really like to understand when the JSR169 check needs to be in the suite vs the test after the small changes to DriverTest. I checked in the change to get the tests running again, but will leave this issue open for a little bit I try to understand that better.
        Hide
        Lily Wei added a comment -

        Thanks Kathey. I look at the derby-5069_diff.txt patch. We will avoid running DriverTest, Driver40Test and Driver40UnbootedTest. I think this is a good start point to get J2ME nightly running again and gather more information so we can understand it better to get the bottom of the problem. +1

        Show
        Lily Wei added a comment - Thanks Kathey. I look at the derby-5069_diff.txt patch. We will avoid running DriverTest, Driver40Test and Driver40UnbootedTest. I think this is a good start point to get J2ME nightly running again and gather more information so we can understand it better to get the bottom of the problem. +1
        Kathey Marsden made changes -
        Issue & fix info [High Value Fix] [High Value Fix, Patch Available]
        Kathey Marsden made changes -
        Attachment derby-5069_diff.txt [ 12471984 ]
        Hide
        Kathey Marsden added a comment -

        Here is the patch to get the J2ME tests running again and adds some diagnostics to make the source of the failure more obvious in the future. I am still not clear on why the new Driver references in DriverTest are problematic while the old ones were not, but put the JSR169 test in jdbcapi._Suite before adding the test to avoid the problem.

        I ran jdbcapi._Suite without error and am going to kick off suites.All now. If it is not done by the end of the day, I will go ahead and check in as I want it to make the weekend runs as I think the release candidate is planned for Monday and it would be good to get the J2ME runs going again before that.

        Show
        Kathey Marsden added a comment - Here is the patch to get the J2ME tests running again and adds some diagnostics to make the source of the failure more obvious in the future. I am still not clear on why the new Driver references in DriverTest are problematic while the old ones were not, but put the JSR169 test in jdbcapi._Suite before adding the test to avoid the problem. I ran jdbcapi._Suite without error and am going to kick off suites.All now. If it is not done by the end of the day, I will go ahead and check in as I want it to make the weekend runs as I think the release candidate is planned for Monday and it would be good to get the J2ME runs going again before that.
        Hide
        Kathey Marsden added a comment -

        The trouble seems to be associated with the addition of this testing to DriverTest
        // test that the driver is one of the special 40 versions if we are running
        // on Java 6 or higher
        println( "Driver is a " + driver.getClass().getName() );
        assertEquals( JDBC.vmSupportsJDBC4(), driver.getClass().getName().endsWith( "40" ) );

        But I am not sure why this particular part of the test is problematic as there are lots of other references to driver that seem to be avoided successfully with this code in the suite() method.
        if (JDBC.vmSupportsJSR169())

        { return new TestSuite( "DriverTest tests java.sql.Driver, not supported with JSR169"); }
        Show
        Kathey Marsden added a comment - The trouble seems to be associated with the addition of this testing to DriverTest // test that the driver is one of the special 40 versions if we are running // on Java 6 or higher println( "Driver is a " + driver.getClass().getName() ); assertEquals( JDBC.vmSupportsJDBC4(), driver.getClass().getName().endsWith( "40" ) ); But I am not sure why this particular part of the test is problematic as there are lots of other references to driver that seem to be avoided successfully with this code in the suite() method. if (JDBC.vmSupportsJSR169()) { return new TestSuite( "DriverTest tests java.sql.Driver, not supported with JSR169"); }
        Hide
        Kathey Marsden added a comment -

        It looks like the Driver40 tests were not excluded for JS169, preventing the full suite from running, but there is something else to. Still getting the error after changing Driver40Test and Driver40UnbootedTest. I am not sure why we don't get a stack trace with the invocation error.

        Show
        Kathey Marsden added a comment - It looks like the Driver40 tests were not excluded for JS169, preventing the full suite from running, but there is something else to. Still getting the error after changing Driver40Test and Driver40UnbootedTest. I am not sure why we don't get a stack trace with the invocation error.
        Kathey Marsden made changes -
        Field Original Value New Value
        Assignee Kathey Marsden [ kmarsden ]
        Hide
        Kathey Marsden added a comment -

        Assigning to myself at least until I figure out what is going on. I see that the Sun J2ME tests have not run since September.

        Show
        Kathey Marsden added a comment - Assigning to myself at least until I figure out what is going on. I see that the Sun J2ME tests have not run since September.
        Kathey Marsden created issue -

          People

          • Assignee:
            Kathey Marsden
            Reporter:
            Kathey Marsden
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development