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
[email protected]
http://qos.ch/mailman/listinfo/logback-user
