Derby
  1. Derby
  2. DERBY-5374

converted ij5Test fails with weme6.2 (CDC/Foundation): junit.framework.ComparisonFailure: Output at line 1 expected:<CONNECTION0* - jdbc:derby:wombat> but was:<ERROR XJ004: Database '' not found.>

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: 10.9.1.0
    • Component/s: Test
    • Labels:
      None
    • Environment:
      windows XP, with weme6.2 (IBM's CDC/Foundation implementation)
    • Bug behavior facts:
      Regression Test Failure

      Description

      The newly converted (to junit) test ij5Test fails with weme 6.2:

      ij5(org.apache.derbyTesting.functionTests.tests.tools.ij5Test)junit.framework.ComparisonFailure: Output at line 1 expected:<CONNECTION0* - jdbc:derby:wombat> but was:<ERROR XJ004: Database '' not found.>
      at junit.framework.AssertionFailedError.<init>(AssertionFailedError.java:11)
      at junit.framework.ComparisonFailure.<init>(ComparisonFailure.java:19)
      at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:109)
      at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:204)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

      This is likely a similar problem as described in DERBY-5373 (re importExportIJ).

      see also (until cleaned up at some point in the future): http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.2/1152992-suites.All_diff.txt

      1. DERBY-5374.diff
        4 kB
        Myrna van Lunteren
      2. DERBY-5374.diff
        3 kB
        Myrna van Lunteren

        Issue Links

          Activity

          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.
          Hide
          Houx Zhang added a comment -

          Thanks for your patient and valuable work, Myrna!

          Show
          Houx Zhang added a comment - Thanks for your patient and valuable work, Myrna!
          Hide
          Bryan Pendleton added a comment -

          Thanks Myrna!

          Show
          Bryan Pendleton added a comment - Thanks Myrna!
          Hide
          Myrna van Lunteren added a comment -

          resolving after commit of the patch with revision 1155163.
          Will close after a round of nightly tests.

          Show
          Myrna van Lunteren added a comment - resolving after commit of the patch with revision 1155163. Will close after a round of nightly tests.
          Hide
          Myrna van Lunteren added a comment -

          somehow the connection0 change didn't make it in the first svn diff.

          Show
          Myrna van Lunteren added a comment - somehow the connection0 change didn't make it in the first svn diff.
          Hide
          Myrna van Lunteren added a comment -

          With weme 6.2 (j2ME/Foundation), with the following in ijTest5:
          if (JDBC.vmSupportsJSR169())

          { props.setProperty("ij.dataSource", "org.apache.derby.jdbc.EmbeddedSimpleDataSource"); props.setProperty("ij.dataSource.databaseName", "wombat"); props.setProperty("ij.dataSource.createDatabase", "create"); }

          I get a diff with weme 6.2 if all three lines are there, because the database was already created. With showNoConnectionsAtStartup=true this gets masked...
          If I comment out the createDatabase property line, I get a diff because of an extra connection (i.e. it shows Connection0 and Connection1. This is because of the CleanDatabase Setup).
          If I comment out also the ij.dataSource.databaseName line, I get an extra line with error message 'XJ004: Database ' ' not found.
          And if I don't set ij.dataSource at all, we get the getURL(String) method not found error.

          In all, I don't think this test can be made to work exactly the same with j2ME as with the more richer jvms.
          In the old harness we handled this sort of difference by adding another master file, but although it would've made the test work, maintaining multiple masters is a nightmare, and as this test never ran with JSR169/j2ME/Foundation, and it's not testing major functionality, but only one test case, I think it's ok to not run this with JSR169/j2ME/Foundation.

          So I'm attaching a patch that I will commit shortly, which skips this test from running with JSR169, both in the test itself and in the tools._Suite.
          In addition, I noticed the .sql file still mentions ConnOne, which was removed, so I changed that to say Connection0.

          Show
          Myrna van Lunteren added a comment - With weme 6.2 (j2ME/Foundation), with the following in ijTest5: if (JDBC.vmSupportsJSR169()) { props.setProperty("ij.dataSource", "org.apache.derby.jdbc.EmbeddedSimpleDataSource"); props.setProperty("ij.dataSource.databaseName", "wombat"); props.setProperty("ij.dataSource.createDatabase", "create"); } I get a diff with weme 6.2 if all three lines are there, because the database was already created. With showNoConnectionsAtStartup=true this gets masked... If I comment out the createDatabase property line, I get a diff because of an extra connection (i.e. it shows Connection0 and Connection1. This is because of the CleanDatabase Setup). If I comment out also the ij.dataSource.databaseName line, I get an extra line with error message 'XJ004: Database ' ' not found. And if I don't set ij.dataSource at all, we get the getURL(String) method not found error. In all, I don't think this test can be made to work exactly the same with j2ME as with the more richer jvms. In the old harness we handled this sort of difference by adding another master file, but although it would've made the test work, maintaining multiple masters is a nightmare, and as this test never ran with JSR169/j2ME/Foundation, and it's not testing major functionality, but only one test case, I think it's ok to not run this with JSR169/j2ME/Foundation. So I'm attaching a patch that I will commit shortly, which skips this test from running with JSR169, both in the test itself and in the tools._Suite. In addition, I noticed the .sql file still mentions ConnOne, which was removed, so I changed that to say Connection0.
          Hide
          Myrna van Lunteren added a comment -

          I've found out the difference between the nightly run and what I was doing on my laptop; in the nightly run it was already having -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource set.
          Without that, like on my laptop, ij will try to connect using java.sql.Driver subclasses, including using a getURL method that's not available on this jvm.

          If memory serves me right, with ij.showNoConnectionsAtStart=false (so, show connections at start, if I understand this double negation) we get a different output between dataSources and Driver connections.
          I'm experimenting to see if there's a way to get the same output still for running with J2ME/CDC and full-fledged jvms, but no luck so far.

          Show
          Myrna van Lunteren added a comment - I've found out the difference between the nightly run and what I was doing on my laptop; in the nightly run it was already having -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource set. Without that, like on my laptop, ij will try to connect using java.sql.Driver subclasses, including using a getURL method that's not available on this jvm. If memory serves me right, with ij.showNoConnectionsAtStart=false (so, show connections at start, if I understand this double negation) we get a different output between dataSources and Driver connections. I'm experimenting to see if there's a way to get the same output still for running with J2ME/CDC and full-fledged jvms, but no luck so far.
          Hide
          Myrna van Lunteren added a comment -

          Hi,

          Apologies if I've been unclear. The failure from the description is seen on the machine where tests are run nightly - this is a Windows XP desktop (I think it's an IBM ThinkCentre). This machine runs suites.All with ibm 1.5, 1.6 and weme 6.2 (which is IBM's implementation of the J2ME/CDC/Foundation profile). The test failure is because at the top of the .out file, there is an extra message 'ERROR XJ004: Database ' ' not found, which isn't in the master (and doesn't show up on the other jvms). I think it's possible that this message would go away if we specify the properties as in DERBY-5346...

          But I tried to reproduce this failure with weme 6.2 on my laptop, which is a Thinkpad T60 with Windows XP - by running the test by itself, by running a modified tools suite, running the full tools suite, and finally running the full suites.All, and I did not see the failure. I used the same weme version on both machines.

          So I'm still struggling to figure out when this happens on the nightly machine.

          The getURL(String) not found message I got on my laptop, in all of the experiments indicated above. I'm confused about that too, because the failure on the nightly machine really indicates that the entire test was executed correctly, which seems impossible based on the behavior on my laptop.

          It would be interesting to know if either of those problems shows with PhoneME, but I don't have access to that.

          Show
          Myrna van Lunteren added a comment - Hi, Apologies if I've been unclear. The failure from the description is seen on the machine where tests are run nightly - this is a Windows XP desktop (I think it's an IBM ThinkCentre). This machine runs suites.All with ibm 1.5, 1.6 and weme 6.2 (which is IBM's implementation of the J2ME/CDC/Foundation profile). The test failure is because at the top of the .out file, there is an extra message 'ERROR XJ004: Database ' ' not found, which isn't in the master (and doesn't show up on the other jvms). I think it's possible that this message would go away if we specify the properties as in DERBY-5346 ... But I tried to reproduce this failure with weme 6.2 on my laptop, which is a Thinkpad T60 with Windows XP - by running the test by itself, by running a modified tools suite, running the full tools suite, and finally running the full suites.All, and I did not see the failure. I used the same weme version on both machines. So I'm still struggling to figure out when this happens on the nightly machine. The getURL(String) not found message I got on my laptop, in all of the experiments indicated above. I'm confused about that too, because the failure on the nightly machine really indicates that the entire test was executed correctly, which seems impossible based on the behavior on my laptop. It would be interesting to know if either of those problems shows with PhoneME, but I don't have access to that.
          Hide
          Houx Zhang added a comment -

          Then, for ij5Test, a JDBC.vmSupportsJSR169() should be added to avoid it run on j2me.

          Hi, Myrna, you've said "I did see another test failure in the ij5 test on my machine though: ", What machine did you run on, please? Is it j2me or a common pc platform?

          Show
          Houx Zhang added a comment - Then, for ij5Test, a JDBC.vmSupportsJSR169() should be added to avoid it run on j2me. Hi, Myrna, you've said "I did see another test failure in the ij5 test on my machine though: ", What machine did you run on, please? Is it j2me or a common pc platform?
          Hide
          Myrna van Lunteren added a comment -

          I was hoping the same thing, but I cannot reproduce the test failure on my machine.

          I did see another test failure in the ij5 test on my machine though:

          1) ij5(org.apache.derbyTesting.functionTests.tests.tools.ij5Test)java.lang.NoSuchMethodError: java/sql/DatabaseMetaData.getURL()Ljava/lang/String;
          at org.apache.derby.impl.tools.ij.ij.showConnectionsMethod(Unknown Source)
          at org.apache.derby.impl.tools.ij.utilMain.supportIJProperties(Unknown Source)
          at org.apache.derby.impl.tools.ij.utilMain.goScript(Unknown Source)
          at org.apache.derby.tools.ij.runScript(Unknown Source)
          at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:191)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

          I will look at that more closely too, but I did notice that the old ij5.sql test did not run with foundation profile, for it had this in ij5_app.properties:
          #Exclude for J2ME/Foundation - test requires java.sql.Driver
          runwithfoundation=false

          Show
          Myrna van Lunteren added a comment - I was hoping the same thing, but I cannot reproduce the test failure on my machine. I did see another test failure in the ij5 test on my machine though: 1) ij5(org.apache.derbyTesting.functionTests.tests.tools.ij5Test)java.lang.NoSuchMethodError: java/sql/DatabaseMetaData.getURL()Ljava/lang/String; at org.apache.derby.impl.tools.ij.ij.showConnectionsMethod(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.supportIJProperties(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.goScript(Unknown Source) at org.apache.derby.tools.ij.runScript(Unknown Source) at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:191) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) I will look at that more closely too, but I did notice that the old ij5.sql test did not run with foundation profile, for it had this in ij5_app.properties: #Exclude for J2ME/Foundation - test requires java.sql.Driver runwithfoundation=false
          Hide
          Bryan Pendleton added a comment -

          Could it be that both DERBY-5373 and DERBY-5374 can be fixed the same way as DERBY-5346?

          I don't have phoneme or weme, but hopefully the solution is to make the same change to ij5Test.java
          and importExportIJTest.java as was made to ij3Test.java in DERBY-5346.

          Show
          Bryan Pendleton added a comment - Could it be that both DERBY-5373 and DERBY-5374 can be fixed the same way as DERBY-5346 ? I don't have phoneme or weme, but hopefully the solution is to make the same change to ij5Test.java and importExportIJTest.java as was made to ij3Test.java in DERBY-5346 .

            People

            • Assignee:
              Unassigned
              Reporter:
              Myrna van Lunteren
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development