db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: CompatibilityTest issue
Date Sat, 11 Nov 2006 10:46:23 GMT
Andrew McIntyre <mcintyre.a@gmail.com> writes:

> On 11/10/06, Ole.Solberg@sun.com <Ole.Solberg@sun.com> wrote:
>> [Auto-generated mail]
>>
>> *tinderbox_trunk15* 473603/2006-11-11 01:52:19 CET
>>
>> Failed  Tests    OK  Skip  Duration       Platform
>> -------------------------------------------------------
>> *Jvm: 1.5*
>>   SunOS-5.10_i86pc-i386
>>     1    516    515     2   120.57%     derbyall
>
> The failure here is in junitTests/derbyNet/CompatibilityTest.java, due
> to my recent checkin for the ant junitreport target, which also sets
> the system property derbyTesting.junit to the location of junit.jar
> with regards to granting permissions for the security manager setup. I
> was hoping that this property would also be set properly in the old
> harness via SecurityManagerSetup, but unfortunately that is not the
> case due to the jvm forking that occurs in the old harness.
>
> The test can be fixed by granting " permission java.io.FilePermission
> "${user.home}${/}junit.properties", "read"; " to all. While this isn't
> necessarily the best fix, it's low risk, and solves the problem of
> this test continuously failing.
>
> The next step up would be to fix the old harness to pass the
> derbyTesting.junit property to forked VMs as necessary. This would fix
> the CompatibilityTest as written to the old junit base class while
> running under the old harness, at the expense of some time modifying
> the old harness.
>
> The ideal fix would be to rewrite CompatibilityTest to extend from
> BaseJDBCTestCase and declare a proper suite method, instead of
> extending from DerbyJunitTest. However, this has proven to be
> non-trivial at this point.
>
> I'm somewhat inclined to remove CompatiblityTest altogether until it
> can be rewritten to conform to our current JUnit usage patterns. But,
> the security policy alteration described above is innocuous enough to
> allow the compatblity test to continue running under the old harness
> for now. So, currently leaning towards the policy alteration so that
> we can keep this particular test running...
>
> Opinions?

I think it's best if we can keep the test running, so I'd go for the
policy alteration until the test can be rewritten. Or to put it
differently, I think compatibility testing is more important than
testing that no part of the code reads junit.properties. :)

-- 
Knut Anders

Mime
View raw message