Hi Myrna,
Thanks, the problem does occur if I remove the Derby test harness from
the picture. I have attached to JIRA 930 a patch which demonstrates the
problem: The Derby drivers fail to autoload when you run under a
SecurityManager. However, they do autoload if you don't install a
SecurityManager.
Hi Dan,
Would appreciate any advice which might occur to you given your
extensive work with SecurityManagers.
Thanks,
-Rick
Myrna van Lunteren wrote:
I am wondering - if you run the test program standalone *with* a
SecurityManager, what do you get?
Myrna
On 2/8/06, *Rick Hillegas* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I am tracking down a problem with autoloading jdbc drivers when
running
from jar files under the Derby test harness on jdk1.6. Capsule
summary:
SUCCESS-1 The drivers correctly autoload (from the information in the
jar file) when I run my test program standalone (without a
SecurityManager)
SUCCESS-2 The drivers also correctly autoload if I run the test under
the Derby test harness but disable the SecurityManager
FAILURE However, the drivers fail to autoload when I run my test
program under the default Derby test harness (which sets up a
SecurityManager)
The vm silently swallows the failure. When I run these test cases with
the the java -verbose flag, I see the following:
o For the success cases, the autoloading of the driver is logged.
o For the failure (Derby test harness) case, around the same place in
the log, I see AccessControlException being loaded. This is never
loaded
in the success cases.
So I seem to have some kind of SecurityManager issue here. But what?
Later on in the failure case, I successfully load the driver using
Class.forName(). What is different in the Derby harness security
environment between autoload time and Class.forName() time? How can I
instrument vm startup to tease open the swallowed
AccessControlException? Would appreciate any advice you may have.
Thanks,
-Rick
