On 5/26/06, Olav Sandstaa <[EMAIL PROTECTED]> 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
