On 3/30/06, Olav Sandstaa <[EMAIL PROTECTED] > wrote:
Rick Hillegas < [EMAIL PROTECTED]> wrote:
> Somewhere in the test output there should be a detailed stack trace for
> this exception (you may have to run the test with verbose=true).  That
> stack trace will point you at a piece of code which may need to be
> wrapped in a privileged block. [snip] You may also need to add some permissions to the policy file used by
> derbyall tests: derby_tests.policy.

Rick, thanks for the hints on how to get the stack trace for where the
security exception occurs and hints on how to fix it. I still hope
that I do not have to do changes related to the security manager and I
am still hoping for some hints for functionality in the test framework
or code other tests on how to start and stop Derby in a less ad hoc
way than I am doing it in this test.
 
[snip]

The security exception is raised when Derby tries to get access to the
log/logmirror.ctrl file during the second startup of the database. I
would have expected that since this file was created earlier during
the initial startup of the test, the test should already have the
required security permissions to access it during the second startup?
 
[snip]

Regards,
Olav
 
As Deepa said, look at TestUtil.getConnection(<dbname>,<propertiesstring>).
I am also wondering if you're walking into DERBY-1069, and the problem is actually some more basic trouble with making the connection.
See also http://www.nabble.com/-jira-Created%3A-%28DERBY-1069%29-Client-should-unwrap-exceptions-thrown-in-privilege-blocks-rather-than-throwing-the-java.security.PrivilegedActionException-t1201470.html#a3170997 on this.
 
Myrna
 

 

Reply via email to