tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: Static loggers
Date Fri, 01 Jun 2018 15:35:45 GMT
2018-06-01 17:13 GMT+03:00 Mark Thomas <markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message