geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <>
Subject Re: [BUILD] trunk: Failed for Revision: 653204
Date Tue, 06 May 2008 08:36:34 GMT
Jason Dillon <jason@...> writes:

> The other option, is to create our own SLF4J implementation, which  
> provides this serialization muck... which may also allow us to add  
> some ability to inject some state into the MDC and/or NDC to provide  
> more details about the logger, like which plugin or which ear they  
> came from, etc...
> --jason


The unqualified recommendation [1] in the SLF4J FAQ for declaring
loggers as instance variables is misleading. I apologize for that. We
recently had a discussion on the slf4j user list on the subject
[2]. Heres is a short summary of that discussion.

Pros for declaring loggers as non-static (instance) variables:

1) they allow for using distinct logger environments, say per
application, by virtue of repository selectors. See also [3].

2) Declaring non-static loggers allows for a copy-and-paste resistant

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyClass {
   private final Logger logger = LoggerFactory.getLogger(getClass());
   ... etc

Cons for declaring loggers as non-static (instance) variables:

1) the commonly admitted idiom calls for static loggers, meaning that
the number of classes with static logger declarations runs in the
millions. Static loggers are not going to disappear any time soon.

2) non-static loggers have a small but still non-negligible
computational cost at initialization of each hosting class instance
(of about 100 nanoseconds)

3) non-static loggers need to be declared as transient in serialized

4) only few applications are known to use repository selectors

5) repository selectors do not work for the SLF4J+log4j combination,
nor for the SLF4J+jul combination

Given the reasons listed above, it seems unreasonable to recommend
developers to declare non-static loggers.


View raw message