https://bz.apache.org/bugzilla/show_bug.cgi?id=59247
--- Comment #15 from Konstantin Kolinko <knst.koli...@gmail.com> --- (In reply to Remy Maucherat from comment #9) > Evidently there's a "bug" somewhere if only the IBM JDK does this. However, > since this is only added to JULI, adding it is probably not a big issue > [which is why I did it], so having a workaround sounds acceptable to me. > > I will challenge your veto on the grounds that it doesn't cause any harm. > Let's see if someone seconds it. Regarding the tomcat 9 patch (juli issue): 1. Allowing "accessClassInPackage.org.apache.catalina.loader" to any web application, as proposed by original patch, is not good. A web application should not have reflective access to WebappClassLoader. 2. Adding this permission for tomcat-juli.jar, as implemented by r1737149, implies that the call chain does not have web application code in it. If it has only Tomcat code in it, it means that this solves this specific use case. It is not some generic feature available to web applications. 3. Preloading a class is how we solved similar issues in the past. Personally, I think that preloading a class provides better life cycle for the Class. The class is explicitly loaded by System classloader. The WebappClassLoader is not involved. If the class uses logging, it will use configuration provided by System classloader, not one provided by TCCL. The trick with preloading is that you need to know what class needs to be loaded. Adding a permission is easier, as this is what java.security.debug logging shows you, but it is harder to evaluate the consequences. >From 2. I do not see much consequences (as web application code is not in the call chain), but I do not see much benefits either. Preloading the class can be tested by adding the class name to the "classesToInitialize" attribute of a JreMemoryLeakPreventionListener in server.xml [2] [2] http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html -- 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
