[logback-user] NOP logger issue/workaround

[Ceki Gülcü]

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