[ 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. -- 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
