You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bryan Pendleton (JIRA)" <de...@db.apache.org> on 2006/03/27 19:32:48 UTC

[jira] Commented: (DERBY-1152) Failures in sysinfo and sysinfo_withproperties induced by classpath wiring

    [ http://issues.apache.org/jira/browse/DERBY-1152?page=comments#action_12372008 ] 

Bryan Pendleton commented on DERBY-1152:
----------------------------------------

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




> Failures in sysinfo and sysinfo_withproperties induced by classpath wiring
> --------------------------------------------------------------------------
>
>          Key: DERBY-1152
>          URL: http://issues.apache.org/jira/browse/DERBY-1152
>      Project: Derby
>         Type: Bug
>   Components: Test
>     Versions: 10.2.0.0
>     Reporter: Rick Hillegas
>     Assignee: Bryan Pendleton

>
> If you wire your classpath together out of the compiled classtree and the checked-in jars, you get the following error in the sysinfo and sysinfo_withproperties tests. You don't see this error if you run against the built Derby jar files:
> 15d14
> < Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read)
> 43d41
> < Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read)
> 72d69
> < Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read)
> Test Failed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira