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. But that would imply using some kind of reloading thread which checks for NOP loggers, which isn't that pretty. Also I would lose any logging calls going on in the meanwhile. Anyone has a good idea on how to prevent SLF4j creating these NOP loggers, or a solution for the workaround? Best regards, Roger
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
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@qos.ch To: logback-user@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@qos.ch http://qos.ch/mailman/listinfo/logback-user
participants (2)
-
Ceki Gülcü -
Rutger Saalmink