https://bz.apache.org/bugzilla/show_bug.cgi?id=59247
--- Comment #8 from Konstantin Kolinko <knst.koli...@gmail.com> ---
>From "java.security.debug stack trace" attachment,
[[[
java.lang.Exception: Stack trace
at java.security.AccessController.throwACE(AccessController.java:144)
at
java.security.AccessController.checkPermissionHelper(AccessController.java:217)
at
java.security.AccessController.checkPermission(AccessController.java:349)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:562)
at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1655)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:322)
at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:836)
at java.lang.ClassLoader.loadClass(ClassLoader.java:823)
at java.lang.ClassLoader.loadClass(ClassLoader.java:803)
at
org.apache.catalina.loader.WebappClassLoaderBase.findResource(WebappClassLoaderBase.java:903)
at
org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:429)
at
org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:402)
at
org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:398)
at java.security.AccessController.doPrivileged(AccessController.java:594)
at
org.apache.juli.ClassLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:398)
at
org.apache.juli.ClassLoaderLogManager.getLogger(ClassLoaderLogManager.java:230)
at java.util.logging.LogManager.demandLogger(LogManager.java:562)
at java.util.logging.Logger.demandLogger(Logger.java:466)
at java.util.logging.Logger.getLogger(Logger.java:513)
at org.apache.juli.logging.DirectJDKLog.<init>(DirectJDKLog.java:68)
at org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:188)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:115)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:206)
at org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:363)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5143)
]]]
The line WebappClassLoaderBase.java:903 where it happens is
> ResourceEntry entry = resourceEntries.get(path);
so IBM JDK refuses WebappClassLoaderBase's right to load class from the same
package and from the same classloader.
This is rather odd behaviour. Isn't it a bug in IBM JDK?
Another thing is that I do not understand is why stacktrace goes into
sun.misc.Launcher$AppClassLoader. The ResourceEntry class shall be loaded by
URLClassLoader() -- the one that loads classes from ${catalina.home}/lib/*.jar
-- created by o.a.c.startup.ClassLoaderFactory during bootstrap time.
Maybe it tries to load something else besides that class, or this is a call to
a parent classloader,
I think that while allowing "accessClassInPackage.org.apache.catalina.loader"
permit to tomcat-juli.jar is rather safe, this permit does not have enough
grounds. (Formally: -1)
I think that this can be solved by preloading the
org.apache.catalina.loader.ResourceEntry class.
a. In an existing version of Tomcat the class can be preloaded by adding its
name to "classesToInitialize" attribute of a JreMemoryLeakPreventionListener
configured in server.xml
b. Permanent solution is to preload the class via
org.apache.catalina.security.SecurityClassLoad class, like many others.
[1]
http://tomcat.apache.org/tomcat-8.0-doc/config/listeners.html#JRE_Memory_Leak_Prevention_Listener_-_org.apache.catalina.core.JreMemoryLeakPreventionListener
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
