2018-06-01 17:13 GMT+03:00 Mark Thomas <ma...@apache.org>: > Hi, > > I've stumbled across a problem with some static loggers. The general > pattern is: > > - TCCL is web application class loader > - static logger is created > - static logger is associated with web application class loader > - web application is undeployed > - appenders are removed from logger > - further logger output is lost > > In most cases we avoid this issue by using a non-static logger. I've > found a few places where we need to switch from static to non-static > loggers. That in turn is triggering some refactoring (as static methods > can't access a non-static logger). > > I should have something ready to commit later today.
So effectively now each web application can have its own logging configuration (in WEB-INF/classes/logging.properties) for those classes. Reviewing r1832692 : OK 1. CallbackHandlerImpl: It exists in one instance only.See "private static CallbackHandler instance;", and the constructor of this class is private. If a web application creates this class, you will have the same problem with lifespan of the logger when the application is undeployed. The bug is not fixed here. 2. Jasper's SecurityClassLoad class It is a bit odd that its logging can be controlled by a web application, but it is OK. 3. Maybe add a comment, e.g. // Non-static. A web application can have its own configuration of logging. Not really needed, but my first thought was that I want to see one. Alternatives: a) a helper method that unsets TCCL, creates a logger and restores TCCL. b) preload the class, but a system property reading bug a month ago showed that simple preloading as done by SecurityClassLoad classes does not cause initialization of static fields. https://bz.apache.org/bugzilla/show_bug.cgi?id=62350#c7 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
