SLF4J project |
Introduction |
News |
Documentation |
License |
Download |
Source Repositories |
Mailing Lists |
Bug Reporting |
Direct implementations |
LOGBack |
NLOG4J |
x4juli |
Wrapped implementations |
JDK14 |
Log4j |
NOP |
Simple |
Simple-Log |
The Simple Logging Facade for Java or (SLF4J) is intended to serve as a simple facade for various logging APIs allowing to plug in the desired implementation at deployment time.
1: import org.slf4j.Logger; 2: import org.slf4j.LoggerFactory; 3: 4: public class Wombat { 5: 6: final Logger logger = LoggerFactory.getLogger(Wombat.class); 7: Integer t; 8: Integer oldT; 9: 10: public void setTemperature(Integer temparature) { 11: 12: oldT = t; 13: t = temperature; 14: 15: logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT); 16: 17: if(temperature.intValue() > 50) { 18: logger.info("Temperature has risen above 50 degrees."); 19: } 20: } 21: }
The example above illustrates the typical usage pattern for SLF4j. Note the use of formatted log messages on line 15. See the question "What is the fastest way of logging?" in the FAQ for more details.
SLF4J currently supports multiple implementations, namely, NOP, Simple, log4j version 1.2, log4j version 1.3, JDK 1.4 logging, JCL and NLOG4J. The SLF4J distribution ships with several jar files slf4j-nop.jar, slf4j-simple.jar, slf4j-log4j12.jar, slf4j-log4j13.jar, slf4j-jdk14.jar and slf4j-jcl.jar. The nlog4j.jar which ships with NLOG4J 1.2.10 and later directly implements SLF4J. Each of these jar files is hardwired at compile-time to use just one implementation, that is NOP, Simple, log4j version 1.2, log4j version 1.3, JDK 1.4 logging, JCL and NLOG4J, respectively.
Small applications where configuring a fully-fledged logging systems can be somewhat of an overkill can drop in slf4j-simple.jar instead of a binding for the fully-fledged logging system.
Authors of widely-distributed components and libraries may code against the SLF4J interface in order to avoid imposing an logging API implementation on the end-user. At deployment time, the end-user may choose the desired logging API implementation by inserting the corresponding jar file in her classpath. This stupid, simple and robust approach avoids many of the painful bugs associated with dynamic discovery processes.
The SLF4J interfaces and their various adapters are extremely simple. Most developers familiar with the Java language should be able to read and fully understand the code in less than one hour.
As noted earlier, SLF4J does not rely on any special class loader machinery. Every variant of slf4j-<impl>.jar is statically hardwired at compile time to use one and only specific implementation. Thus, SLF4J suffers from none of the class loader problems observed when using JCL.
Hopefully, the simplicity of the SLF4J interfaces and the deployment model will make it easy for developers of other logging APIs to conform to the SLF4J model.
The Logger
class in NLOG4J directly implements
SLF4J's Logger
interface. Moreover, NLOG4J makes
extensive use of SLF4J internally.
NLOG4J's built-in support for SLF4J means that the adapter
for NLOG4J does not need to wrap NLOG4J objects in order to
make them conform to SLF4J's Logger
interface. A
NLOG4J Logger
is a
org.slf4j.Logger
. Thus, using SLF4J in
conjunction with NLOG4J involves strictly zero memory overhead
and near-zero computational overhead.
To ease migration to SLF4J from JCL, recent SLF4J distributions include the jar file jcl104-over-slf4j.jar. This jar file is intended as a drop-in replacement for JCL version 1.0.4. It implements the public API of JCL but using SLF4J underneath, hence the name "JCL over SLF4J."
Our JCL over SLF4J implementation will allow you to migrate to SLF4J gradually, especially if some of the libraries your software depends on continue to use JCL for the foreseeable future. You can immediately enjoy the benefits of SLF4J's reliability and preserve backward compatibility at the same time. Just replace commons-logging.jar with jcl104-over-slf4j.jar. Subsequently, the selection of the underlying logging system will be done by SLF4J instead of JCL but without the class loader headaches. The underlying logging system can be any of NOP, simple, jdk14 logging, log4j or NLOG4J. Any existing dependency on commons-logging therefore becomes less of an issue.
If you are still hesitating to make the switch to SLF4J instead of JCL, you might be interested to learn that SLF4J offers a JCL binding. The JCL binding found in the file slf4j-jcl.jar will delegate all logging calls made through SLF4J API to the JCL API. Thus, if for some reason an existing application must use JCL, your part of that application can still code against the SLF4J API in a manner transparent to the larger application environment. Your choice of SLF4J API will be invisible to the rest of the application which can continue to use JCL.
In summary, jcl104-over-slf4j.jar comes in handy when the application environment depends on the SLF4J API but other third party libraries relying on commons-logging need to be supported. On the other hand, slf4j-jcl.jar is useful in case the larger application environment uses JCL. An application component can still use SLF4J without disrupting the larger application. In fact, slf4j-jcl.jar will delegate all logging decisions to JCL so that the dependency on SLF4J API by the smaller component will be transparent to the larger whole.
Please note that jcl104-over-slf4j.jar and slf4j-jcl.jar cannot be deployed at the same time. The former jar file will cause JCL to delegate the choice of the logging system to SLF4J and the latter jar file will cause SLF4J to delegate the choice of the logging system to JCL, resulting in an infinite loop.
Advantage | Description |
---|---|
Swappable logging API implementations | The desired logging API can be plugged in at deployment time by inserting the appropriate jar file on your classpath. |
Fail-safe operation | Assuming the appropriate jar file is available on the
classpath, under no circumstances will SLF4J cause your
application to fail. SLF4J's simple and robust design
ensures that SLF4J never causes exceptions to be thrown.
Contrast this with
|
Adapter implementations for popular logging systems | SLF4J supports popular logging systems, namely log4j, JDK 1.4 logging, Simple logging and NOP. |
Easy migration path | The implementation of JCL over SLF4J will allow your
project to migrate to SLF4J piecemeal, without breaking
compatibility with existing software, while enhancing the
reliability of your software at the same time.
In existing applications where JCL is a requirement, the JCL binding will allow parts of that application to switch to SLF4J without having any impact on the larger application. |
Support for formated log messages | All SLF4J adapters support formated log messages with significantly improved performace results. |