db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: jdk16 and suite derbyall - 128 failures
Date Wed, 31 May 2006 11:16:16 GMT
On 5/26/06, Olav Sandstaa <Olav.Sandstaa@sun.com> wrote:
> >> I think I have found what causes the Nist tests to fail when running
> >> derbyall with jdk16. The Nist tests started to fail after DERBY-930
> >> (Add support for autoloading of Derby client drivers) was check in.
> >>
[...snip...]
> >>
> So basically the Nist tests fail due to the embedded driver is loaded
> before derby.system.home is set to the value that it should have for the
> test.  And this leads to the security exception when the VM trying to
> get the canonical path name for the current directory.
>
[...snip...]
> So how should we fix this? Any suggestions? Some ideas:
>
> * Remove the support for autoloading of the embedded driver (Yes, Rick
> and the JDBC4 expert group have already said no to this, but I still
> think there are situations where automagic loading of the drivers is a
> bad idea)
>
> * Change the test harness so that derby.system.home is set to a value
> that is OK for all tests suites (running with useprocess=false) early
> during initialization (before touching any JDBC driver code)
>
> * Change the  RunSuite(?) code so that it unloads the embedded driver
> and the engine as part of the start  up  (to get rid of the autoloaded
> embedded driver)
>
> * Change the "security manager" properties for  the  Nist tests to avoid
> the security exception when the VM tries to get the canonical path for
> the working directory.
>
> Any preferences or suggestions for better ideas?
>
> Thanks,
> Olav
>
I think setting derby.system.home for useprocess=false runs may be
achievable...even if we decide to keep the autoloading.

Another option may be to add additional permissions to the
useprocessfalse.policy file in functionTests/util...would that be
acceptable (if it works)? I guess it would need user.dir read? for
derby.jar? (user.dir read appears to be in place - in
derby_tests.policy - currently for derbytools.jar, derbyTesting.jar
and classes).

While this gets hashed out further, maybe it's time to create a
separate bug for this, and document the investigative work there...
Then maybe we can stop jdk16 from running nist (runwithjdk16=false in
nist.properties) for the time being, so we don't lose the signal value
of the automatic reports...

Myrna

Mime
View raw message