Derby
  1. Derby
  2. DERBY-2076

Rewrite junitTests/derbyNet/CompatibilityTest to conform to current JUnit usage

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: 10.10.1.1
    • Component/s: Test
    • Labels:
      None

      Description

      The test org.apache.derbyTesting.functionTests.tests.junitTests.DerbyNet.CompatibilityTest has been failing in the nightlies because it needs to be run in the old test harness, and for some reason the property which grants permission to read $

      {user.home}/junit.properties is not being picked up properly in the old harness.

      I am able to resolve the problem by granting permission to read ${user.home}

      /junit.properties to all, but the test should be refactored so that it can run with the rest of the junit tests without needing the old harness.

      1. compiler-level.patch
        1 kB
        Knut Anders Hatlen
      2. derby-2076-0a-modernized_compat_test_preview.diff
        171 kB
        Kristian Waagan
      3. derby-2076-0b-modernized_compat_test_preview.diff
        121 kB
        Kristian Waagan
      4. derby-2076-1a-initial.diff
        132 kB
        Kristian Waagan
      5. derby-2076-1b-initial.diff
        163 kB
        Kristian Waagan
      6. derby-2076-2a-enable_test.diff
        0.6 kB
        Kristian Waagan

        Issue Links

          Activity

          Hide
          Andrew McIntyre added a comment -

          Granted permission to read $

          {user.home}

          /junit.properties to all with revision 474593 to fix the test running in the old harness.

          Show
          Andrew McIntyre added a comment - Granted permission to read $ {user.home} /junit.properties to all with revision 474593 to fix the test running in the old harness.
          Hide
          Kristian Waagan added a comment -

          Attaching patch 0a, which is a preview of the work I'm doing on this issue.

          This is just for the curious I'll write a proper comment tomorrow, listing various issues with the compatibility test.

          You can run this if you want to. I find it best to use the swingui TestRunner - there you can see the structure of the suites. To apply the patch, do something like this:
          mkdir java/testing/org/apache/derbyTesting/functionTests/tests/compatibility
          svn add ava/testing/org/apache/derbyTesting/functionTests/tests/compatibility
          svn copy java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/CompatibilitySuite.java java/testing/org/apache/derbyTesting/functionTests/tests/compatibility/AbstractCompatibilityTest.java
          svn copy java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/JDBCDriverTest.java java/testing/org/apache/derbyTesting/functionTests/tests/compatibility/
          patch -p0 < derby-2076-0a-modernized_compat_test_preview.diff

          To run the test you have to specify derbyTesting.oldReleasePath, which should preferably point to the Derby release JAR repos (https://svn.apache.org/repos/asf/db/derby/jars), and you have to run off jars:
          java -classpath derby_jars:junit.jar -DderbyTesting.oldReleasePath=release_jars_dir -Dderby.tests.debug=true -Dderby.tests.trace=true junit.swingui.TestRunner org.apache.derbyTesting.functionTests.tests.compatibility._Suite

          Show
          Kristian Waagan added a comment - Attaching patch 0a, which is a preview of the work I'm doing on this issue. This is just for the curious I'll write a proper comment tomorrow, listing various issues with the compatibility test. You can run this if you want to. I find it best to use the swingui TestRunner - there you can see the structure of the suites. To apply the patch, do something like this: mkdir java/testing/org/apache/derbyTesting/functionTests/tests/compatibility svn add ava/testing/org/apache/derbyTesting/functionTests/tests/compatibility svn copy java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/CompatibilitySuite.java java/testing/org/apache/derbyTesting/functionTests/tests/compatibility/AbstractCompatibilityTest.java svn copy java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/JDBCDriverTest.java java/testing/org/apache/derbyTesting/functionTests/tests/compatibility/ patch -p0 < derby-2076-0a-modernized_compat_test_preview.diff To run the test you have to specify derbyTesting.oldReleasePath, which should preferably point to the Derby release JAR repos ( https://svn.apache.org/repos/asf/db/derby/jars ), and you have to run off jars: java -classpath derby_jars:junit.jar -DderbyTesting.oldReleasePath=release_jars_dir -Dderby.tests.debug=true -Dderby.tests.trace=true junit.swingui.TestRunner org.apache.derbyTesting.functionTests.tests.compatibility._Suite
          Hide
          Myrna van Lunteren added a comment -

          There's a patch attached to this issue by Kristian, from last year September but never committed...Is more work on this forthcoming?

          Show
          Myrna van Lunteren added a comment - There's a patch attached to this issue by Kristian, from last year September but never committed...Is more work on this forthcoming?
          Hide
          Kristian Waagan added a comment -

          Yes, there is more work forthcoming.

          I ended up being out for several months when I was working on this, so I'll have to restart the effort. There are more related changes going in.
          In any case, I think it will be good to sort out the existing issues before I do more on this issue - some of the changes are substantial (but should only affect specific test groups, like the CompatibilityTest and the UpgradeTest). This is part of getting rid of the very first JUnit framework code we wrote.

          I'll add a link to the other relevant issue(s) later.

          Show
          Kristian Waagan added a comment - Yes, there is more work forthcoming. I ended up being out for several months when I was working on this, so I'll have to restart the effort. There are more related changes going in. In any case, I think it will be good to sort out the existing issues before I do more on this issue - some of the changes are substantial (but should only affect specific test groups, like the CompatibilityTest and the UpgradeTest). This is part of getting rid of the very first JUnit framework code we wrote. I'll add a link to the other relevant issue(s) later.
          Hide
          Myrna van Lunteren added a comment -

          That's great to know, thanks for working on this issue, Kristian!
          My curiosity was sparked because a recent failure in this test in one of our nightly runs. I was wondering if I should commit the patch but that doesn't sound like a good idea.
          Certainly there are other issues with higher priority currently.

          Show
          Myrna van Lunteren added a comment - That's great to know, thanks for working on this issue, Kristian! My curiosity was sparked because a recent failure in this test in one of our nightly runs. I was wondering if I should commit the patch but that doesn't sound like a good idea. Certainly there are other issues with higher priority currently.
          Hide
          Kristian Waagan added a comment -

          If you already have the patch ready and it fixes a problem that's bothering you there's no reason not to commit it.
          Thinking about the refactoring/rewrite it would be good to have a description of the problem so that it can be avoided in the new version.

          To be honest, I fear it might be a little while before I get around to continue this work.

          Show
          Kristian Waagan added a comment - If you already have the patch ready and it fixes a problem that's bothering you there's no reason not to commit it. Thinking about the refactoring/rewrite it would be good to have a description of the problem so that it can be avoided in the new version. To be honest, I fear it might be a little while before I get around to continue this work.
          Hide
          Myrna van Lunteren added a comment -

          The test failure that - briefly - sparked my interest was on January 26, with ibm 1.7, on windows:

          http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm17/1236495-derbyall_diff.txt
          The diff is:
          -----------------

              • Start: CompatibilityTest jdk1.7.0 DerbyNetClient derbynetclientmats:derbynetclientmats 2012-01-27 03:32:29 ***
                0 add
                > Exception in thread "main" java.sql.SQLException: java.net.ConnectException : Error connecting to server xxxFILTERED_HOSTNAMExxx on port 1527 with message Connection refused: connect.
                > Caused by: org.apache.derby.client.am.DisconnectException: java.net.ConnectException : Error connecting to server xxxFILTERED_HOSTNAMExxx on port 1527 with message Connection refused: connect.
                > ... 8 more
                > Caused by: java.net.ConnectException: Connection refused: connect
                > ... 14 more
                Test Failed.
                ----------------------------
                Unfortunately, I don't have any further details - the test directory has been lost by now.

          This test does not fail frequently. In fact, I checked and don't see records of it failing at all last year, and only the once this year. So this doesn't have high priority for me.
          I have no patch to contribute.

          Show
          Myrna van Lunteren added a comment - The test failure that - briefly - sparked my interest was on January 26, with ibm 1.7, on windows: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm17/1236495-derbyall_diff.txt The diff is: ----------------- Start: CompatibilityTest jdk1.7.0 DerbyNetClient derbynetclientmats:derbynetclientmats 2012-01-27 03:32:29 *** 0 add > Exception in thread "main" java.sql.SQLException: java.net.ConnectException : Error connecting to server xxxFILTERED_HOSTNAMExxx on port 1527 with message Connection refused: connect. > Caused by: org.apache.derby.client.am.DisconnectException: java.net.ConnectException : Error connecting to server xxxFILTERED_HOSTNAMExxx on port 1527 with message Connection refused: connect. > ... 8 more > Caused by: java.net.ConnectException: Connection refused: connect > ... 14 more Test Failed. ---------------------------- Unfortunately, I don't have any further details - the test directory has been lost by now. This test does not fail frequently. In fact, I checked and don't see records of it failing at all last year, and only the once this year. So this doesn't have high priority for me. I have no patch to contribute.
          Hide
          Kristian Waagan added a comment -

          Attaching an updated version of the modernized compatibility test. Here's what running the MATS looks like (with trace and debug enabled):

          $ java -cp "..\jars\sane\derbyrun.jar;..\jars\sane\derbyTesting.jar;..\tools\java\junit.jar" -DderbyTesting.oldReleasePath=$( cygpath --windows ~/winhome/Documents/derby/releases ) -Dderby.tests.trace=true junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.compatibility._Suite

          {ReleaseRepository}

          19 candidate releases at C:\Users\kwaagan\Documents\derby\releases
          skipped invalid distribution: C:\Users\kwaagan\Documents\derby\releases\10.0.2.1
          .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.10.0.0 used 4134 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.8.2.2 <> server 10.10.0.0 used 2091 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.7.1.1 <> server 10.10.0.0 used 2074 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.6.2.1 <> server 10.10.0.0 used 2075 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.5.3.0 <> server 10.10.0.0 used 1576 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.4.2.0 <> server 10.10.0.0 used 1575 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.3.3.0 <> server 10.10.0.0 used 1576 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.2.2.0 <> server 10.10.0.0 used 1560 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.1.3.1 <> server 10.10.0.0 used 1560 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.8.2.2 used 3634 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.7.1.1 used 3120 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.6.2.1 used 3120 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.5.3.0 used 3104 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.4.2.0 used 3136 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.3.3.0 used 3634 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.2.2.0 used 2605 ms .
          (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.1.3.1 used 3120 ms
          Time: 73,692

          OK (17 tests)

          This is still not ready for commit.
          Given this will be enabled by default in suites.All, do people prefer that the test fails if there are no old releases available, or rather that an ALARM statement is printed?

          Show
          Kristian Waagan added a comment - Attaching an updated version of the modernized compatibility test. Here's what running the MATS looks like (with trace and debug enabled): $ java -cp "..\jars\sane\derbyrun.jar;..\jars\sane\derbyTesting.jar;..\tools\java\junit.jar" -DderbyTesting.oldReleasePath=$( cygpath --windows ~/winhome/Documents/derby/releases ) -Dderby.tests.trace=true junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.compatibility._Suite {ReleaseRepository} 19 candidate releases at C:\Users\kwaagan\Documents\derby\releases skipped invalid distribution: C:\Users\kwaagan\Documents\derby\releases\10.0.2.1 . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.10.0.0 used 4134 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.8.2.2 <> server 10.10.0.0 used 2091 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.7.1.1 <> server 10.10.0.0 used 2074 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.6.2.1 <> server 10.10.0.0 used 2075 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.5.3.0 <> server 10.10.0.0 used 1576 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.4.2.0 <> server 10.10.0.0 used 1575 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.3.3.0 <> server 10.10.0.0 used 1576 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.2.2.0 <> server 10.10.0.0 used 1560 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.1.3.1 <> server 10.10.0.0 used 1560 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.8.2.2 used 3634 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.7.1.1 used 3120 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.6.2.1 used 3120 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.5.3.0 used 3104 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.4.2.0 used 3136 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.3.3.0 used 3634 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.2.2.0 used 2605 ms . (net)compatibility.ClientCompatibilityRunControl.client 10.10.0.0 <> server 10.1.3.1 used 3120 ms Time: 73,692 OK (17 tests) This is still not ready for commit. Given this will be enabled by default in suites.All, do people prefer that the test fails if there are no old releases available, or rather that an ALARM statement is printed?
          Hide
          Kristian Waagan added a comment -

          Attaching patch 1a, which is the intial check-in of the new modernized compatibility test.

          See the package.html for some description. It may be helpful to generate and read the Javadocs too.
          The actual tests, with some modifications, have been taken from the old compatibility test. Most of the supporting code, i.e. spawning the server and the client and the combination generator, is new.

          The new version is lacking the ability to run with multiple JVM versions. That feature can be added after the initial patch has been committed - given that people feel it is worth keeping. I imagine that feature would only be used in the more comprehensive test suites, and not as part of the MATS variant run in suites.All.

          I intend to commit this shortly to allow for easier testing of the new test. I hope to include the MATS variant of the test in suites.All after it has been sufficiently tested and remaining issues have been addressed.
          I do believe that committing the current code is better than reviewing this large chunk of code because it allows others to easily contribute by running the tests on their systems, and because this will be opt-in. The current/old compatibility test will continue to run until the community feel comfortable to do the switch.

          The drawback of having two versions is that two versions have to be maintained, but there are typically few modifications to the compatibility tests (too few?). I hope that over the summer we have made enough progress to determine the final action, which will hopefully be to delete the old test and start using new one exclusively.

          Patch ready for review.

          Show
          Kristian Waagan added a comment - Attaching patch 1a, which is the intial check-in of the new modernized compatibility test. See the package.html for some description. It may be helpful to generate and read the Javadocs too. The actual tests, with some modifications, have been taken from the old compatibility test. Most of the supporting code, i.e. spawning the server and the client and the combination generator, is new. The new version is lacking the ability to run with multiple JVM versions. That feature can be added after the initial patch has been committed - given that people feel it is worth keeping. I imagine that feature would only be used in the more comprehensive test suites, and not as part of the MATS variant run in suites.All. I intend to commit this shortly to allow for easier testing of the new test. I hope to include the MATS variant of the test in suites.All after it has been sufficiently tested and remaining issues have been addressed. I do believe that committing the current code is better than reviewing this large chunk of code because it allows others to easily contribute by running the tests on their systems, and because this will be opt-in. The current/old compatibility test will continue to run until the community feel comfortable to do the switch. The drawback of having two versions is that two versions have to be maintained, but there are typically few modifications to the compatibility tests (too few?). I hope that over the summer we have made enough progress to determine the final action, which will hopefully be to delete the old test and start using new one exclusively. Patch ready for review.
          Hide
          Kristian Waagan added a comment -

          FYI, here's the number of combinations computed for the various suites, including 10.9.1.0 and excluding 10.0.2.1 [1]:
          o _Suite: 19
          o _SuiteDevFull: 39
          o _SuiteOld: 100
          o _SuiteOldFull: 400

          These numbers include combinations where client X is tested against server X.

          [1] 10.0.2.1 is excluded because it doesn't have a client driver. The old/current test uses the client from the closest newer Derby-version instead, but I don't see the point in that. In fact, I'm considering adding a cutoff value, such that we ignore all versions older than a given version by default.

          Show
          Kristian Waagan added a comment - FYI, here's the number of combinations computed for the various suites, including 10.9.1.0 and excluding 10.0.2.1 [1] : o _Suite: 19 o _SuiteDevFull: 39 o _SuiteOld: 100 o _SuiteOldFull: 400 These numbers include combinations where client X is tested against server X. [1] 10.0.2.1 is excluded because it doesn't have a client driver. The old/current test uses the client from the closest newer Derby-version instead, but I don't see the point in that. In fact, I'm considering adding a cutoff value, such that we ignore all versions older than a given version by default.
          Hide
          Kristian Waagan added a comment -

          Attaching patch 1b, which is the same as patch 1a except that it is generated with Subversion and that I factored out moving assertDirectoryDeleted to DERBY-5836.

          Committed patch 1b to trunk with revision 1354960.

          The new test is ready for testing. Just run JUnit pointing at _Suite. More information with derby.tests.trace=true and derby.tests.debug=true.

          Show
          Kristian Waagan added a comment - Attaching patch 1b, which is the same as patch 1a except that it is generated with Subversion and that I factored out moving assertDirectoryDeleted to DERBY-5836 . Committed patch 1b to trunk with revision 1354960. The new test is ready for testing. Just run JUnit pointing at _Suite. More information with derby.tests.trace=true and derby.tests.debug=true.
          Hide
          Kristian Waagan added a comment -

          Committed a small change with revision 1355147, where I modified java/testing/build.xml to compile the old compatibility test before the new one. The opposite order causes a support class to be compiled with JDK 1.5 instead of JDK 1.4, and that casues the old compatibility test to fail because it runs a set of tests with J2SE 1.4.2.

          Show
          Kristian Waagan added a comment - Committed a small change with revision 1355147, where I modified java/testing/build.xml to compile the old compatibility test before the new one. The opposite order causes a support class to be compiled with JDK 1.5 instead of JDK 1.4, and that casues the old compatibility test to fail because it runs a set of tests with J2SE 1.4.2.
          Hide
          Knut Anders Hatlen added a comment -

          We should probably stop running the compatibility tests with Java 1.4 in the Tinderbox. But it looks like it's failing on tests that run on Java 5 too: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-1355057.html

          Show
          Knut Anders Hatlen added a comment - We should probably stop running the compatibility tests with Java 1.4 in the Tinderbox. But it looks like it's failing on tests that run on Java 5 too: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-1355057.html
          Hide
          Kristian Waagan added a comment -

          Thanks, Knut.

          I didn't notice the other test failing yesterday. But the error message looks similar:
          "Caused by: org.apache.derby.client.am.SqlException: Java exception: 'org.apache.derbyTesting.functionTests.tests.lang.Price : Bad version number in .class file: java.lang.ClassNotFoundException'."

          I don't have the other error message in front of me now, but I think it mentioned the class files versions (i.e. 49 and 50). Not sure if/how the above error is different. However, I do see that the compile target in the new build.xml file is set to 1.6, which is probably just a copy and paste error.

          Show
          Kristian Waagan added a comment - Thanks, Knut. I didn't notice the other test failing yesterday. But the error message looks similar: "Caused by: org.apache.derby.client.am.SqlException: Java exception: 'org.apache.derbyTesting.functionTests.tests.lang.Price : Bad version number in .class file: java.lang.ClassNotFoundException'." I don't have the other error message in front of me now, but I think it mentioned the class files versions (i.e. 49 and 50). Not sure if/how the above error is different. However, I do see that the compile target in the new build.xml file is set to 1.6, which is probably just a copy and paste error.
          Hide
          Knut Anders Hatlen added a comment -

          The new compatibility test suite fails with a class version error when it runs on Java 5. Changing the compiler level from $

          {compilerLevel16}

          to 1.5 (see compiler-level.patch) makes it pass.

          Show
          Knut Anders Hatlen added a comment - The new compatibility test suite fails with a class version error when it runs on Java 5. Changing the compiler level from $ {compilerLevel16} to 1.5 (see compiler-level.patch) makes it pass.
          Hide
          Knut Anders Hatlen added a comment -

          Committed compiler-level.patch to trunk with revision 1359070.

          Show
          Knut Anders Hatlen added a comment - Committed compiler-level.patch to trunk with revision 1359070.
          Hide
          Kristian Waagan added a comment -

          Attached patch 2a, which enables the test in suites.All.

          Since I haven't gotten any feedback on testing, I've decided to enable the test and see what happens

          If you don't have the old releases in the default location, and don't specify derbyTesting.oldReleasePath, you may see an ALARM statement printed to the console.
          The test doesn't require any specific versions, it will test with whatever old versions of Derby that are made available. This is different from some other tests.

          Committed patch 2a to trunk with revision 1367428.

          Show
          Kristian Waagan added a comment - Attached patch 2a, which enables the test in suites.All. Since I haven't gotten any feedback on testing, I've decided to enable the test and see what happens If you don't have the old releases in the default location, and don't specify derbyTesting.oldReleasePath, you may see an ALARM statement printed to the console. The test doesn't require any specific versions, it will test with whatever old versions of Derby that are made available. This is different from some other tests. Committed patch 2a to trunk with revision 1367428.
          Hide
          Kristian Waagan added a comment -

          Linking to DERBY-5889.
          This problem is not caused by the modernized version of the compatibility test, but is rather a product issue regarding handling of UNC paths on Windows.
          It is also a test issue because the UNC path handling in SecurityManagerSetup is broken.

          Show
          Kristian Waagan added a comment - Linking to DERBY-5889 . This problem is not caused by the modernized version of the compatibility test, but is rather a product issue regarding handling of UNC paths on Windows. It is also a test issue because the UNC path handling in SecurityManagerSetup is broken.
          Hide
          Kristian Waagan added a comment -

          Resolving issue.

          There is one potential issue, reported by Mamta on derby-dev [1]. If we want to change the current intended behavior, that can be done under a separate issue.

          [1] http://mail-archives.apache.org/mod_mbox/db-derby-dev/201210.mbox/%3CCAFy7pk81zco6C5wQU2Ud2GhLP=ZpuxTP37op-O+0EAbejtwiXw@mail.gmail.com%3E

          Show
          Kristian Waagan added a comment - Resolving issue. There is one potential issue, reported by Mamta on derby-dev [1] . If we want to change the current intended behavior, that can be done under a separate issue. [1] http://mail-archives.apache.org/mod_mbox/db-derby-dev/201210.mbox/%3CCAFy7pk81zco6C5wQU2Ud2GhLP=ZpuxTP37op-O+0EAbejtwiXw@mail.gmail.com%3E

            People

            • Assignee:
              Kristian Waagan
              Reporter:
              Andrew McIntyre
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development