I have written in the past a few introductory posts to SFL4J based on version 1.6.4 that are now obsolete (as
Peter correctly pointed out). Here I consider mainly that, since version 1.6.6, SLF4J SimpleLogger supports configuration properties. This makes more attractive the SimpleLogger usage, at least for a tiny project, or for early stages of development.
The process of installing SLF4J has not changed at all in this time, you should go to the official SLF4J download page, fetch the latest package available (currently version 1.7.5), extract the content in your preferred local directory. If, for any reason, you need a previous version, you could go and fetch it from the SLF4J repository.
I have written a tiny two-class Java application to check logging at work. The main class, named Hello, does some logging and then create an object of the other class (that I named Another):
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Hello {
public static void main(String[] args) {
Logger logger = LoggerFactory.getLogger(Hello.class);
logger.info("an info message");
try { Thread.sleep(472); } catch(Exception e) {}
logger.error("an error message");
try { Thread.sleep(123); } catch(Exception e) {}
logger.trace("a trace message");
try { Thread.sleep(42); } catch(Exception e) {}
logger.warn("a warn message");
try { Thread.sleep(105); } catch(Exception e) {}
logger.debug("a debug message");
new Another();
}
}
The other class, Another, is even simpler:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Another {
public Another() {
Logger logger = LoggerFactory.getLogger(Another.class);
logger.info("an info message");
logger.error("an error message");
}
}
To build these classes, you need to put in classpath the SLF4J API jar, named slf4j-api-1.7.5.jar (version number may vary).
The minimal configuration to run my application requires to see the same SLF4J API jar in its classpath. Forgetting it leads to a java.lang.NoClassDefFoundError for org/slf4j/LoggerFactory. Otherwise you would get a friendly warning from SLF4J, that could be translated "You didn't say where I should send your log, so I would just swallow your messages, sending them to the NO-OP plugin. If this is not the behavior you expected, you'd better check the documentation":
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html (...)
And if you check the documentation, you would see that you have to put in the classpath another jar, that would determine how the logger should behave.
The NOP implementation is contained in slf4j-nop-1.7.5.jar, if you put this jar in the classpath, you will get the same result as above (nothing logged), without the showed reminder.
If you want SLF4J to delegate to JUL the logging, you should put slf4j-jdk14-1.7.5.jar in the classpath. JUL is the standard Java Logger, (java.util.logging is its package name), included in the JDK since version 1.4, and the SLF4J plugin used in this case acts as a bridge to that log implementation. For my example, I get this output:
Apr 19, 2013 8:18:45 PM Hello main
INFO: an info message
Apr 19, 2013 8:18:46 PM Hello main
SEVERE: an error message
Apr 19, 2013 8:18:46 PM Hello main
WARNING: a warn message
Apr 19, 2013 8:18:46 PM Another
INFO: an info message
Apr 19, 2013 8:18:46 PM Another
SEVERE: an error message
Let's finally see what I get if I put in the classpath slf4j-simple-1.7.5.jar, the SLF4J simple logging plugin.
[main] INFO Hello - an info message
[main] ERROR Hello - an error message
[main] WARN Hello - a warn message
[main] INFO Another - an info message
[main] ERROR Another - an error message
In square brackets we have the thread name, then we see the log level, then the logger name, and finally the log message.
The interesting part is that now we can specify a file, named simplelogger.properties, where we could set some configuration variables. More details in the official SLF4J documentation, but let's see a sample configuration file, and which is its impact on the log generation:
#default is System.err
#org.slf4j.simpleLogger.logFile = simple.log
#trace, debug, info, warn, error - default is info
org.slf4j.simpleLogger.defaultLogLevel = trace
org.slf4j.simpleLogger.log.Another = error
#default is false
org.slf4j.simpleLogger.showDateTime = true
#default is milliseconds since startup
org.slf4j.simpleLogger.dateTimeFormat = HH.mm.ss:SSS
#default is true
org.slf4j.simpleLogger.showThreadName = false
If we specify the org.slf4j.simpleLogger.logFile property, the log is redirected to the file named in that way. By default the special name System.err is used, that is a placeholder for the standard error console.
The default loglevel is info, meaning only info and above are usually logged, but we can change it setting the org.slf4j.simpleLogger.defaultLogLevel property. Here I say that I want to see all the logging (being trace the lowest available level).
I can set the loglevel for a specific class (or package), setting a org.slf4j.simpleLogger.log.* property. Here you can see that for the class Another I want to dump only the top level log messages (namely, errors).
Usually date/time is not shown in the log, to have it we should specify that org.slf4j.simpleLogger.showDateTime is true.
If we don't specify the date/time format, and we specify that we want it showed, we see the number of milliseconds from the application startup. The org.slf4j.simpleLogger.dateTimeFormat is used to specify a different format. Here I ask for the its time as hour-minute-second:milliseconds.
If I don't care of the thread name, I can say that I don't want it to be logged, setting the org.slf4j.simpleLogger.showThreadName to false.
With such a simplelogger.properties, the resulting log is something like:
20.51.11:015 INFO Hello - an info message
20.51.11:488 ERROR Hello - an error message
20.51.11:612 TRACE Hello - a trace message
20.51.11:654 WARN Hello - a warn message
20.51.11:760 DEBUG Hello - a debug message
20.51.11:761 ERROR Another - an error message
Go to the full post
