Myrna van Lunteren wrote:
On 5/26/06, Olav Sandstaa <[EMAIL PROTECTED]> wrote:
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.
I agree that this is the easiest way to fix the problem. The "problem"
with this solution is that we need to set it early during startup of
derbyall (before any JDBC driver is attempted loaded) and that this
derby.system.home location will be used by all suites running with
useprocess=false. Another issue with this solution is to decide what
directory we should set it to. Should we set derby.system.home to the
current directory where derbyall is started? This would potentially
leave files in the top directory that could influence on other test
suites. Or should we make a sub directory that is common for all suites
running with useprocess=false (and jdk16)? Any suggestion for what value
we should assign to derby.system.home if we decide to do this?
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).
I think this would work, at least if I disable the security manger the
Nist tests succeed. The drawback with this solutions is that it too will
use the directory where derbyall was started for creating the database
and storing files containing test results.
Right now I am experimenting with a solution that attempts to unload the
embedded driver each time a new suite with useprocess=false is started.
If this works I think this will be the best solution since then each
suite can set derby.system.home to the directory they want the test to
run in and then load the driver and engine. Any objections to this
approach? (I do not know yet if it will work)
While this gets hashed out further, maybe it's time to create a
separate bug for this, and document the investigative work there...
I agree. I will file a JIRA for this and make a summary.
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...
Good idea. Unless someone with the right permissions to get this quickly
into the svn repository will do it, I can make a patch for this change
to the property file.
Regards,
Olav
