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.

Myrna van Lunteren
added a comment - 19/Oct/07 01:27 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.

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..

Myrna van Lunteren
added a comment - 19/Oct/07 19:40 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..

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.

Myrna van Lunteren
added a comment - 23/Oct/07 20:07 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.

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.

Knut Anders Hatlen
added a comment - 26/Oct/07 12:07 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.

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...

Myrna van Lunteren
added a comment - 09/Nov/07 21:05 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...