Myrna van Lunteren wrote:
However, sysinfo, accessing java.class.path, lives in both
derbytools.jar and derby.jar and also in derbynet.jar. So, I imagine,
when running with jars, if derby.jar is first in the classpath, that
will be the sysinfo that is being picked up, and so, it can't access
java.class.path.
Thanks Myrna! That is exactly the behavior I see, too.
Meanwhile, while experimenting with different orders of jars in my
classpath, I also discovered that the following two lines were added
to the derby.jar and derbynet.jar, but NOT to the derbytools.jar:
// BUG DERBY-622 derbynet/sysinfo.java
permission java.io.FilePermission "${derbyTesting.codedir}${/}*", "read";
This causes the access to the locale message jars to be inconsistent,
depending on which jar sysinfo is loaded from.
So, depending on the details of my classpath, I can create *three*
different behaviors for the derbynet/sysinfo.java test:
1) If I run with jars, with either derby.jar or derbynet.jar first, I
get the behavior which matches the master files that I submitted:
- java.class.path cannot be accessed
- locale message jars can be accessed.
2) If I run with classes, I get the behavior which Rick & Dan described:
- java.class.path can be accessed.
- locale message jars can be accessed.
3) If I run with jars, but with derbytools.jar first, I get still a
third behavior:
- java.class.path can be accessed.
- locale message jars cannot be accessed.
Perhaps the easiest way out, at this point, is to make the following changes:
1) Add
permission java.util.PropertyPermission "java.class.path", "read";
for derby.jar, derbynet.jar, and derbytools.jar in derby_tests.policy
2) Add
// BUG DERBY-622 derbynet/sysinfo.java
permission java.io.FilePermission "${derbyTesting.codedir}${/}*", "read";
to derbytools.jar in derby_tests.policy
3) Update the master files to reflect that the sysinfo tests are allowed
to read both java.class.path AND the locale message jars.
What do you think?
thanks,
bryan
