On 10/02/2010 09:47, Henning wrote: > Chris, > > yes I did. The code below was meant to be a simplified example. I > created a bug report on that in the meantime: > https://issues.apache.org/bugzilla/show_bug.cgi?id=48716 > > As far I understand now, once the default LogManager of the JDK got > used (i.e. by retrieving a logger or setting defaul logging config), > LogManager.getLogManager() will consistently return that LogManager > implementation and never JULI's. > > JULI however calls LogManager.getLogManager().reset() as a side effect > of a context stop() (e.g. when removing an app from tomcat) so that all > JDK logging config gets reset :-( > > I understand that the intention of JULI is to only reset the > configuration associated with the WebappLoader and it does so, once it > had its own LogManager implementation registered. When embedding tomcat > and using JDK Logging that is however almost certainly not the case.
You need to use a class loader aware LogManager (such as JULI) else you run the risk of memory leaks and other unexpected behaviour (which is why JULI was written in the first place). For example, without JULI webapps that share the same logger name will also share a logger which, if each app has it's own log file, means the log messages for both applications will end up in the log file for whichever app triggered the creation of the logger. Similar issues exist with some of Tomcat's internal loggers. As far as I recall, memory leaks became an issue only if the web application uses any custom Handlers or Formatters. The simple solution is to just use JULI. If, you don't like the JULI implementation for some reason you can either write your own or suggest a patch to improve JULI. > If you are involved with JULI, you might be able to provide a good > solution. I thought testing whether the current LogManager is indeed > JULI's before calling reset could be a remedy. But as I don't know JULI > by heart, there might be other problems in that. Class loader aware LogManagers need to know when they can clean up the logging for a class loader. If the reset() call was only made for the JULI LogManager that would break other non-JULI class loader aware LogManagers. The reset() call needs to be there to enable both JULI and non-JULI class loader aware LogManagers to operate correctly. There may be some very specific configurations that work with the Standard JDK LogManager but I would want to do an awful lot of testing to make sure there weren't any issues before I went with such an approach. If it were safe to the standard LogManagerm, then the reset() call would break things. In that case - and that case only - an option would be required to avoid the call. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
