Guilhem Lavaux wrote: > Jeroen Frijters wrote: > > Gary Benson wrote: > > > >>Guilhem Lavaux wrote: > >> > >>>3) One solution of the problem is to load some core classes. But it > >>>will appear quite soon that some other classes may also be loaded > >>>for really wicked applications. It is a limitative solution and I > >>>would not support it. > >> > >>Yes. Exactly which classes need loading depends on exactly > what your > >>custom checkPermission is doing. We can, of course, make > sure we have > >>the classes we need for the default checkPermission, but > that doesn't > >>seem complete somehow. > > > > > > I must say that I don't understand this problem. Shouldn't the boot > > class loader be able to load classes regardless of the > SecurityManager? > > It would seem to me that VMs that can't do that are broken > and that this > > is not a Classpath problem. > > > > Regards, > > Jeroen > > > > > > Hi Jeroen, > > I do not think it is strictly linked to the VM. > > I have produced an "artificial" stack trace by tweaking kaffe's VM. > Normally this stack trace is hidden by the VM and > replaced by a NoClassDefFoundError. Here I removed the class > preloading > from my test. You can see there is a loop in CharsetProvider at least. > Maybe it's VM related but it would be really weird. > > > This block is the loop: > > at testSM$MySM.checkPermission (testSM.java:17) > at java.lang.SecurityManager.checkSecurityAccess > (SecurityManager.java:1011) > at java.security.Security.getProperty (Security.java:396) > at java.lang.SecurityManager$1.run (SecurityManager.java:1055) > at java.security.AccessController.doPrivileged > (AccessController.java:96) > at java.lang.SecurityManager.checkPackageList > (SecurityManager.java:1051) > at java.lang.SecurityManager.checkPackageAccess > (SecurityManager.java:920) > at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108) > at java.lang.ClassLoader.loadClass (ClassLoader.java:294) > > The last loadClass is already loading java/security/Permission and > checkPermission needs to load java/security/Permission too. > Maybe it is also a SystemProperties trouble ?
This still looks like a VM bug to me. java/security/Permission shouldn't be loaded through the application class loader, but the boot class loader. Regards, Jeroen _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
