If I ever implement the classloading scheme for code sharing, I would
need to find out where the current class was loaded from, and I would
need the same permissions. Although maybe I can take advantage of the
work sysinfo is already doing.
David
Andrew McIntyre (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1152?page=comments#action_12373171 ]
Andrew McIntyre commented on DERBY-1152:
----------------------------------------
Sorry for the late reply, but yes, I believe adding these permissions to the
test policy is ok. There are only two places in the code we try to get the
classpath, sysinfo and the client trace code, both handle security exceptions,
and I think it's unlikely that we'll need to get the contents of the classpath
elsewhere, but you never know. Maybe we should mark this bug number in the
policy file for future reference in case anyone wonders why these permissions
were added. I can take care of that as I follow up on DERBY-622.
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
Fix For: 10.2.0.0
Attachments: derby-1152-looser-policy.diff
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.
