Derby
  1. Derby
  2. DERBY-4647

BaseTestCase.execJavaCmd() does not work with weme 6.2

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.8.2.2, 10.9.1.0
    • Component/s: Test
    • Environment:
    • Urgency:
      Normal

      Description

      Spawning a java process with BaseTestCase.execJavaCmd() does not work with weme 6.2, I think because the boot classpath does not get passed. This issue came up in DERBY-4179. After this issue is fixed, BootLockTest should be enabled for weme.

      The error is actually
      .JVMJ9VM011W Unable to load jclfoun10_24: The specified module could not be foun
      d.
      JVMEXEX013E Internal VM error: Failed to create Java VM
      JVMEXEX014I Run C:\cygwin\ibmsvn\ntsoftware\weme6.2\bin\j9.exe -help for usage

      execJavaProcess does pick up the j9 executable but does not pass on the other settings.

      This is how my script invokes the test with j9. It probably has a lot of legacy system properties not needed, but I suppose execJavaCmd should just pass along all system properties, but I don't know how it would get the bootclasspath. Perhaps -Dbootcp was a way to pass it on in the old harness.

      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 junit.textui.TestRunner org.apache.derbyTesting.fun
      ctionTests.tests.store.BootLockTest

      Otherwise, currently I think the method is only used in replication and network server, but am not sure.

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          [bulk update: close all resolved issues that haven't had any activity the last year]

          Show
          Knut Anders Hatlen added a comment - [bulk update: close all resolved issues that haven't had any activity the last year]
          Hide
          Kathey Marsden added a comment -

          Attached is a patch for this issue. I am running tests now.
          I would appreciate if someone familiar with PhoneME could look at it.

          For BootLockTest, J9 (weme 6.2) does not require derby.database.forceDatabaseLock to be set, so now this is only needed for PhoneME() but we don't currently have an isPhoneMEPlatform() method so I am just using
          if (JDBC.vmSupportsJSR169() && !isJ9Platform()). What is the best way to identify PhoneME()?

          Show
          Kathey Marsden added a comment - Attached is a patch for this issue. I am running tests now. I would appreciate if someone familiar with PhoneME could look at it. For BootLockTest, J9 (weme 6.2) does not require derby.database.forceDatabaseLock to be set, so now this is only needed for PhoneME() but we don't currently have an isPhoneMEPlatform() method so I am just using if (JDBC.vmSupportsJSR169() && !isJ9Platform()). What is the best way to identify PhoneME()?
          Hide
          Kathey Marsden added a comment -

          Linking to DERBY-4179 as that was where this issue was discovered and BootLockTest should be enabled for weme once this issue is fixed.

          Show
          Kathey Marsden added a comment - Linking to DERBY-4179 as that was where this issue was discovered and BootLockTest should be enabled for weme once this issue is fixed.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development