Derby
  1. Derby
  2. DERBY-2903

RunClassPathTester regression test gets diff because of error message difference

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.3.2.1, 10.4.1.3
    • Component/s: Test
    • Labels:
      None
    • Environment:
    • Bug behavior facts:
      Regression Test Failure

      Description

      Got the following diff because of access vs. Access in error message. probably a master update needed.

                      • Diff file derbyall/demo/demo/RunClassPathTester.diff
          • Start: RunClassPathTester jdk1.4.2 demo:demo 2007-06-20 14:32:54 ***
            3 del
            < Unable to access Protection Domain or Code Source for class interface org.apache.derby.database.Database:
            access denied (java.lang.RuntimePermission getProtectionDomain)
            3a3
            > Unable to access Protection Domain or Code Source for class interface org.apache.derby.database.Database:
            Access denied (java.lang.RuntimePermission getProtectionDomain)
            5 del
            < Unable to access Protection Domain or Code Source for class class SimpleApp:
            access denied (java.lang.RuntimePermission getProtectionDomain)
            5a5
            > Unable to access Protection Domain or Code Source for class class SimpleApp:
            Access denied (java.lang.RuntimePermission getProtectionDomain)
            Test Failed.
          • End: RunClassPathTester jdk1.4.2 demo:demo 2007-06-20 14:32:56 ***
      1. DERBY-2903_noapimod.diff2
        11 kB
        Myrna van Lunteren
      2. DERBY-2903_noapimod.diff
        10 kB
        Myrna van Lunteren
      3. DERBY-2903_modapi.diff
        8 kB
        Myrna van Lunteren

        Issue Links

          Activity

          Hide
          Myrna van Lunteren added a comment -

          With revision 593635 I reinstated the test.
          I found that if I changed the call in sysinfo.Main to LocalizedResource from
          LocalizedResource.getInstance() to LocalizedResource.getInstance().init() the problems I saw with reassigning system.out went away.

          I think, that anytime sysinfo was run after a previous call to LocalizedResource.getInstance().init(), for instance through a call to ij.runScript, it didn't actually go to System.out anymore but to wherever the LocalizedResource was pointing.
          I think forcing init() makes more sense for sysinfo, than tagging on to whatever LocalizedResource happens to be pointing.

          After the change to sysinfo.Main, the output now can be controlled using calls to System.setOut(), and I modified the test to no longer use the awkward mechanism of separating and unraveling the output for each test case (command) using System.out.println of a character. Also, now it no longer matters where the test runs, so I removed the comments in tools._Suite.java.

          With revision 593643 I addressed the 2 nits from Knut Anders' review (thx). I did not put the last reset of System.setOut in a finalize...

          Show
          Myrna van Lunteren added a comment - With revision 593635 I reinstated the test. I found that if I changed the call in sysinfo.Main to LocalizedResource from LocalizedResource.getInstance() to LocalizedResource.getInstance().init() the problems I saw with reassigning system.out went away. I think, that anytime sysinfo was run after a previous call to LocalizedResource.getInstance().init(), for instance through a call to ij.runScript, it didn't actually go to System.out anymore but to wherever the LocalizedResource was pointing. I think forcing init() makes more sense for sysinfo, than tagging on to whatever LocalizedResource happens to be pointing. After the change to sysinfo.Main, the output now can be controlled using calls to System.setOut(), and I modified the test to no longer use the awkward mechanism of separating and unraveling the output for each test case (command) using System.out.println of a character. Also, now it no longer matters where the test runs, so I removed the comments in tools._Suite.java. With revision 593643 I addressed the 2 nits from Knut Anders' review (thx). I did not put the last reset of System.setOut in a finalize...
          Hide
          Knut Anders Hatlen added a comment -

          Two small nits:

          1) outputEncoding is both an (unused) instance variable and a local variable in testClassPathChecker. I think one of them should be removed (if the instance variable is kept, it would probably be better to make it static final)

          2) rawBytes is only needed in the test method, so I think it could be a local variable instead of an instance variable. Then we could also get rid of the tearDown() method

          I don't understand the System.out problems, so I can't help you there. You may also consider putting the final setSystemOut() into a finally clause (or perhaps tearDown()) so that we don't end up redirecting System.out for all subsequent tests if sysinfo.main() fails.

          Show
          Knut Anders Hatlen added a comment - Two small nits: 1) outputEncoding is both an (unused) instance variable and a local variable in testClassPathChecker. I think one of them should be removed (if the instance variable is kept, it would probably be better to make it static final) 2) rawBytes is only needed in the test method, so I think it could be a local variable instead of an instance variable. Then we could also get rid of the tearDown() method I don't understand the System.out problems, so I can't help you there. You may also consider putting the final setSystemOut() into a finally clause (or perhaps tearDown()) so that we don't end up redirecting System.out for all subsequent tests if sysinfo.main() fails.
          Hide
          Myrna van Lunteren added a comment -

          Attaching another attempt at this patch - I redid the assignments of System.out, basically copying the approach of org.apache.derbyTesting.functionTests.util.HarnessJavaTest, but it gives the same troubles.

          I think the trouble is not with either of the nomodapi approaches, but with the top two tests in the tools._Suite, or, more specifically, with the two tests that run BaseJDBCTestCase.runSQLCommands. Unless my searches have been off, there are only two tests in the suites.All that use this method...
          If I the new SysinfoCPCheckTest which redirects System.out is run after either IJRunScriptTest or ImportExportTest, the output never is redirected. I've tried closing various streams in the test framework code, all to no avail. I think there is possibly something about ij is run that affects this.

          So, I'll place the new test above those two offending tests.

          If this approach is not acceptable, please speak up; otherwise, I'll commit.

          Show
          Myrna van Lunteren added a comment - Attaching another attempt at this patch - I redid the assignments of System.out, basically copying the approach of org.apache.derbyTesting.functionTests.util.HarnessJavaTest, but it gives the same troubles. I think the trouble is not with either of the nomodapi approaches, but with the top two tests in the tools._Suite, or, more specifically, with the two tests that run BaseJDBCTestCase.runSQLCommands. Unless my searches have been off, there are only two tests in the suites.All that use this method... If I the new SysinfoCPCheckTest which redirects System.out is run after either IJRunScriptTest or ImportExportTest, the output never is redirected. I've tried closing various streams in the test framework code, all to no avail. I think there is possibly something about ij is run that affects this. So, I'll place the new test above those two offending tests. If this approach is not acceptable, please speak up; otherwise, I'll commit.
          Hide
          Myrna van Lunteren added a comment -

          Unfortunately, when running the test as per the nomodapi patch in ...functionTests.tests.tools._Suite, the output goes to System.out after all.
          Back to the drawing board; switching off patch available.

          Note, I also added some carriage returns in the description and env - just cosmetically, so this bug hopefully needs less horizontal space..

          Show
          Myrna van Lunteren added a comment - Unfortunately, when running the test as per the nomodapi patch in ...functionTests.tests.tools._Suite, the output goes to System.out after all. Back to the drawing board; switching off patch available. Note, I also added some carriage returns in the description and env - just cosmetically, so this bug hopefully needs less horizontal space..
          Hide
          Myrna van Lunteren added a comment -

          Attaching 2 patches that represent approaches to convert this test to junit
          1 (modapi.diff) modifies the API slightly so you can run the ClasspathTesting as an API, so the test can look similar to the (currently not running) sysinfoAPITest.
          2. (nonapimod.diff) only adds a test, does not modify the api. This took me some time because for some reason I could not get reassignments of sysinfo.main output to System.out to work iteratively. This patch has better comments also.

          Test not yet added to any suite in the patch.

          If I don't hear any nays I will commit patch DERBY-2903_noapimod.diff and add it to the tools suite.

          Show
          Myrna van Lunteren added a comment - Attaching 2 patches that represent approaches to convert this test to junit 1 (modapi.diff) modifies the API slightly so you can run the ClasspathTesting as an API, so the test can look similar to the (currently not running) sysinfoAPITest. 2. (nonapimod.diff) only adds a test, does not modify the api. This took me some time because for some reason I could not get reassignments of sysinfo.main output to System.out to work iteratively. This patch has better comments also. Test not yet added to any suite in the patch. If I don't hear any nays I will commit patch DERBY-2903 _noapimod.diff and add it to the tools suite.
          Hide
          Myrna van Lunteren added a comment -

          This is a jvm issue - some versions of IBM JVM have that 'Access' instead of 'access'.
          I'll see if I can mask it, or convert the test to junit.

          Show
          Myrna van Lunteren added a comment - This is a jvm issue - some versions of IBM JVM have that 'Access' instead of 'access'. I'll see if I can mask it, or convert the test to junit.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development