Rick Hillegas wrote:
Hi Kristian,
I believe you have run into DERBY-623. I am attaching a patched
version of BaseMonitor which fixes this problem for me. I haven't' run
derbyall against this yet so I can't verify that it's safe. But
methinks it will work for you.
You are correct Rick. Thanks for the info!
I must take some time and search Jira (and the archives) before I post
to dev next time I stumble over something that looks like a bug...
I just looked at the patch quickly, and it solves the problem in the
same way I was thinking about. I will try it out. Any specific reason
why the patch is not attached to DERBY-623 in Jira?
Also, the issue description indicates that there are already methods for
reading system properties in privileged blocks "in the engine". Can
anyone familiar with the code give a hint?
I would like to see this bug fixed, and I am willing to put some work
into it (review, or possibly fix patch to use existing functionality),
unless someone else has the itch for it. I suppose another part of the
fix would be to remove the extra PropertyPermissions from the test
security policy.
--
Kristian
Regards,
-Rick
Kristian Waagan wrote:
Hello,
I have run into a problem when running a JDBC4 JUnit test. The test
is compiled with Mustang (Java 1.6), and all you need in the test for
the problem to arise is a
'Class.forName("org.apache.derby.jdbc.EmbeddedDriver")'.
When the above codeline is executed, a
java.lang.ExceptionInInitializerError is raised with the following
cause:
Caused by: java.security.AccessControlException: access denied
(java.util.PropertyPermission derby.debug.false read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:321)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at java.lang.System.getProperty(System.java:652)
at
org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown
Source) at
org.apache.derby.impl.services.monitor.FileMonitor.<init>(Unknown
Source) at
org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown
Source) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown
Source) at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown
Source) at
org.apache.derby.jdbc.EmbeddedDriver.<clinit>(Unknown Source)
... 18 more
The code causing the error is only reachable in sane builds, and is
located in 'impl.services.monitor.BaseMonitor.runWithState()':
if (SanityManager.DEBUG) {
// Look for the derby.debug.* properties.
if (applicationProperties != null) {
// MODIFIED [snip]
}
// MODIFIED - The error happens here!
addDebugFlags(System.getProperty(Monitor.DEBUG_FALSE), false);
addDebugFlags(System.getProperty(Monitor.DEBUG_TRUE), true); }
There are at least two workarounds; grant more permissions in the
derby_test.policy file (without a codebase argument), or use a
doPrivileged-block around the Class.forName() call.
However, the two options above do not seem right to me.
Can we move the doPrivileged-block down into the BaseMonitor class?
There is also a Properties variable in BaseMonitor named
systemProperties, but glancing at the code tells me it might be null
(haven't checked the consequences of that).
Can anyone advice on this?
--
Kristian
[snip - BaseMonitor patch]
