[logback-user] NOP logger issue/workaround

[Rutger Saalmink]

Hi Ceki,

Thanks for your fast response. Are there any there any other known causes for SLF4j in combination with Logback to create a NOP logger? Only ones i found were:
- parallel Loggerfactory.getLogger() calls.
- not able to bind.

Your proposal of reassignment may be risky in the second case:
    Logger initializingLogger = LoggerFactory.getLogger("temporary.SLF4J.initializing.logger");
    while ("NOP".equals(initializingLogger.getName())){
      //  sleep/wait a little until other thread finished getLogger() call
      initializingLogger = LoggerFactory.getLogger("temporary.SLF4J.initializing.logger");
    }  
    // continue with (normal) instantiation of the actual logger.


Best regards,

Rutger






> Date: Wed, 28 Sep 2011 10:35:32 +0200
> From: ceki at qos.ch
> To: logback-user at qos.ch
> Subject: Re: [logback-user] NOP logger issue/workaround
> 
> Hi Rutger,
> 
> Response in line.
> 
> On 28/09/2011 10:02 AM, Rutger Saalmink wrote:
> > Hi all,
> >
> > Currently I am developing a logging class for weblogic, which functions
> > as a tool for writing to a set of logfiles. Several types of external
> > parties access this class (e.g. other classes, jars, services, etc),
> > potentially concurrent calls. Conceptually it looks like this:
> >
> > public class myClass{
> > private static Logger loggerLog = LoggerFactory.getLogger(myClass.class);
> > private static Logger logA = LoggerFactory.getLogger("my.logA");
> > private static Logger logB = LoggerFactory.getLogger("my.logB");
> >
> > public static boolean logStringToA(final String strValue){
> > loggerLog.info("Write String to log A.");
> > logA.info(strValue);
> > }
> >
> > public static boolean logNodeToB(final Node nodeValue){
> > loggerLog.info("Write Node to log B.");
> > // do some stuff with the Node
> > logB.info(nodeToStringFunction(nodeValue));
> > }
> > }
> >
> > The problem is that SLF4j gets instantiated with NOP loggers on the
> > first calls to the public methods, possibly due to:
> > http://bugzilla.slf4j.org/show_bug.cgi?id=106
> > http://bugzilla.slf4j.org/show_bug.cgi?id=176
> >
> > To fix this problem I try to reload the logback configuration at
> > run-time, explained in
> > http://logback.qos.ch/manual/configuration.html#joranDirectly . However,
> > this means that I will have to reinitialize the loggers in myClass
> > (another call to LoggerFactory.getLogger()) before logging starts.
> 
> Yes, that is correct.
> 
> > But that would imply using some kind of reloading thread which checks for
> > NOP loggers, which isn't that pretty.
> 
> You could check the type of the returned logger. If it was of type 
> NOPLogger, you could simply reassign the logger reference (loggerLog, 
> logA and logB). No additional thread would be necessary.
> 
> > Also I would lose any logging  calls going on in the meanwhile.
> 
> Yes.
> 
> > Anyone has a good idea on how to prevent SLF4j creating these NOP
> > loggers, or a solution for the workaround?
> 
> The solution proposed in bug 176 is probably the way to go. Depending on 
> the use case, reassignment of the logger reference would be a simple
> albeit cumbersome solution.
> 
> > Best regards,
> >
> > Roger
> 
> HTH,
> 
> -- 
> http://twitter.com/ceki
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-user/attachments/20110929/5f0ba887/attachment-0001.html>