tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat JULI resets JDK logging?
Date Wed, 10 Feb 2010 11:11:16 GMT
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:
>   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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message