[slf4j-user] Best practice on declaring Loggers

[Simon Kitching]

BTW, this page really just says what Ceki already said in his email.

And yes, in static methods you really need to call
LoggerFactory.getLogger for each invocation of the method to ensure the
code will work when deployed in a "shared" classloader.

Or it might be passed the logger in a parameter, or somehow retrieve the
logger from one of its parameter objects. That reduces the problem back
to the "instance variable" solution.

Cheers,

Simon

On Thu, 2006-06-15 at 23:00 +1200, Simon Kitching wrote:
> This page is from the wiki for the apache commons-logging project, but
> the same general principles apply to SLF4J too (and is explicitly
> discussed):
> 
> http://wiki.apache.org/jakarta-commons/Logging/StaticLog
> 
> Regards,
> 
> Simon
> 
> On Wed, 2006-06-14 at 11:17 +1000, whoman at exemail.com.au wrote:
> > Gday all,
> > This would seem to imply that to log in static methods we should issue a 
> > LoggerFactory.getLogger() on every invocation  and thus be able to log into 
> > the correct context. Is this accurate, assuming it's not an often used method.
> > Cheers,
> > Will
> > 
> > At 06:12 AM 14/06/2006, you wrote:
> > 
> > 
> > >At 12:30 PM 6/13/2006, Konstantinos Karadamoglou wrote:
> > >>Hello all,
> > >>
> > >>Which is the best practice of declaring Loggers? For instance, should 
> > >>they be static, private, final? and why?
> > >
> > >I recommend that loggers members be declared as instance variables instead 
> > >of static.
> > >
> > >Static logger members cost a single variable reference for all instances 
> > >of the class whereas an instance logger member will cost a variable 
> > >reference for every instance of the class. For simple classes instantiated 
> > >thousands of times there might be a noticeable difference.
> > >
> > >However, more recent logging systems, e.g log4j or logback, support a 
> > >distinct logger context for each application running in the application 
> > >server. Thus, even if a single copy of log4j.jar or logback-classic.jar is 
> > >deployed in the server, the logging system will be able to differentiate 
> > >between applications and offer a distinct logging environment for each 
> > >application.
> > >
> > >More specifically, each time a logger is retrieved by invoking 
> > >LoggerFactory.getLogger() method, the underlying logging system will 
> > >return an instance appropriate for the current application. Please note 
> > >that within the same application retrieving a logger by a given name will 
> > >always return the same logger.
> > >
> > >If the logger is static, then it will only be retrieved once when the 
> > >hosting class is loaded into memory. If the hosting class is used in only 
> > >in one application, there is not much to be concerned about. However, if 
> > >the hosting class is shared between several applications, then all 
> > >instances of the shared class will log into the context of the application 
> > >which happened to fist load the shared class into memory.
> > >
> > >In summary, except for classes with few members and instantiated very 
> > >frequently, logger members should be instance variables.
> > >
> > >I hope this helps,
> > >
> > >--
> > >Ceki Gülcü
> > >http://ceki.blogspot.com/
> > >
> > >_______________________________________________
> > >user mailing list
> > >user at slf4j.org
> > >http://slf4j.org/mailman/listinfo/user
> > >
> > 
> > 
> > 
> > _______________________________________________
> > user mailing list
> > user at slf4j.org
> > http://slf4j.org/mailman/listinfo/user
> 
> _______________________________________________
> user mailing list
> user at slf4j.org
> http://slf4j.org/mailman/listinfo/user