Workaround for running JUnit tests with the GUI runners (was: Re: [junit] Making progess faster towards a pure Junit world)

[Kristian Waagan <Kr...@Sun.COM>]

Dyre.Tjeldvoll@Sun.COM wrote:
> Kristian Waagan <Kr...@Sun.COM> writes:
> 
>> Daniel John Debrunner wrote:

[ snip - progress towards a pure JUnit world ]

> 
> Should it be possible to run junit tests with ALL the junit runners,
> or just with junit.textui.TestRunner? 
> 
> With the current trunk I able to
> run
> 
> org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite
> 
> successfully with junit.textui.TestRunner (if I set
> derby.system.home), but with 
> junit.awtui.TestRunner or junit.swingui.TestRunner the first test
> fails with 
> 
> java.lang.ExceptionInInitializerError
> 	at org.apache.derbyTesting.junit.TestConfiguration.defaultSecurityManagerSetup(TestConfiguration.java:667)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:73)
> 	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)
> Caused by: java.lang.NullPointerException
> 	at org.apache.derbyTesting.junit.SecurityManagerSetup.determineClasspath(SecurityManagerSetup.java:218)
> 	at org.apache.derbyTesting.junit.SecurityManagerSetup.<clinit>(SecurityManagerSetup.java:56)
> 	... 19 more
> 
> and the following tests fail with
> 
> java.lang.NoClassDefFoundError: Could not initialize class org.apache.derbyTesting.junit.SecurityManagerSetup
> 	at org.apache.derbyTesting.junit.TestConfiguration.defaultSecurityManagerSetup(TestConfiguration.java:667)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:73)
> 	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)
> 
> Should I create a JIRA for this?

Hi Dyre,

I think you can create a Jira for this, if you haven't already.

The problem is that the GUI runners are using a custom classload to 
allow for dynamic reloading of the test classes. It defeats the getURL 
method in SecurityManagerSetup, seemingly by returning an empty/null 
(the object itself isn't null) ProtectionDomain object. This finally 
leads to the URL object extracted being null, which causes the NPE.

A workaround is to specify the -noloading option for the runner, like this:
java -classpath X junit.swingui.TestRunner -noloading 
org.apache.derbyTesting...

If you do this, you must restart the GUI if you recompile the test classes.
We should investigate this and see if we can get it working without 
specifying the -noloading argument.



-- 
Kristian

> 

Re: Workaround for running JUnit tests with the GUI runners

[Knut Anders Hatlen <Kn...@Sun.COM>]

Kristian Waagan <Kr...@Sun.COM> writes:

> Hi Dyre,
>
> I think you can create a Jira for this, if you haven't already.
>
> The problem is that the GUI runners are using a custom classload to
> allow for dynamic reloading of the test classes.

I'm seeing this message in derby.log when I'm running with (any)
TestRunner:

DEBUG RAFContainerFactory OUTPUT: Caught exception when setting up
rafContainerConstructor

The tests don't fail because RAFContainerFactory falls back to the old
RAFContainer implementation. The exception seems to be a
ClassNotFoundException (cannot find RAFContainer4). Could it also be
caused by the custom classloader?

-- 
Knut Anders

Re: Workaround for running JUnit tests with the GUI runners (was: Re: [junit] Making progess faster towards a pure Junit world)

[Dy...@Sun.COM]

Kristian Waagan <Kr...@Sun.COM> writes:

[snip]

>> Should I create a JIRA for this?
>
> Hi Dyre,
>
> I think you can create a Jira for this, if you haven't already.

Thank you for an excellent analysis, Kristian! 

Logged as 
https://issues.apache.org/jira/browse/DERBY-1977

> The problem is that the GUI runners are using a custom classload to
> allow for dynamic reloading of the test classes. It defeats the getURL
> method in SecurityManagerSetup, seemingly by returning an empty/null
> (the object itself isn't null) ProtectionDomain object. This finally
> leads to the URL object extracted being null, which causes the NPE.
>
> A workaround is to specify the -noloading option for the runner, like this:
> java -classpath X junit.swingui.TestRunner -noloading
> org.apache.derbyTesting...
>
> If you do this, you must restart the GUI if you recompile the test classes.
> We should investigate this and see if we can get it working without
> specifying the -noloading argument.

-- 
dt