Daniel John Debrunner wrote:
Kristian Waagan wrote:
Kristian Waagan wrote:
Daniel John Debrunner wrote:
Julius.Stroffek wrote:
[ snip - suggestion about using non-standard option -Xbootclasspath ]
Does anyone see any showstoppers for this approach?
I tested a small sample with Sun VMs. Does it work for VMs from other
vendors?
FYI, I tested this with IBM's VMs (1.4 and 1.5) and also with JRockit
(1.4 and 1.5). They all seem to honor the
-Xbootclasspath/a:<comma-separated-list> option/syntax.
Is it possible to determine if the test class is running from the
bootclasspath? This would then allow the suite() method to determine if
the class should run or not. Seems like the unit package-protected class
tests should only run if:
using classes || loaded from boot classpath
And potentially some functional tests should not run in the boot
classpath, e.g. those that would test what happens if a security
permission is not granted, e.g. create a database in a folder with no
write permission. I'm assuming here that classes in the boot class path
have all permissions, is that correct?
Yes, they will be looked at the same way as the java.* classes are.
If you put derby.jar in the boot class path and derbyTesting.jar on the
class path, the security restrictions only apply to code calling
"restricted code" in derbyTesting (for instance FileWriter.write).
As soon as you move into derby.jar, you have all permissions. So if you
have the required OS privileges, you can create a database anywhere even
though the policy file states you are only allowed to do so in directory X.
Can we catch SecurityException (and check for sealing violation) when we
load the test classes and also try to load a Derby class at the same time?
Or get the class loader of a class, and check if it is null?
From the JavaDoc, it is not possible to conclude that the bootstrap
class loader is always null ("Some implementations may use null to
represent the bootstrap class loader."), and getting the class loader
might require permission to do so.
I think the functional tests should be run in a separate VM when run
from jars. When running from classes, we can run all tests (except those
testing jar-specific behavior).
Another option is to let tests that cannot run in the boot class path be
aware of that and return an empty suite, but this doesn't seem right to
me (increased complexity, insignificant gain).
It is a problem that the sealing violation can occur at different
places, depending on which jar/class we load first.
If a testing class is loaded first, an exception will be thrown when the
test loads a class from a Derby jar file.
If Derby is loaded first, the suite() method of the testing class will
never be reached.
Maybe the checking should be done in a class from derbyTesting if
possible, and if we agree to link the two together?
Currently, I'm more in favor of keeping the two sets of tests separate
by running them in different VMs. Might be some incorrect statements in
the mail, haven't really thought everything through, but please correct
me so we can work this issue out and see if the approach is feasible!
--
Kristian
Thanks,
Dan.
