Slf4j Jar File Download
Jacalyn Nier
The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks, such as java.util.logging, log4j 1.x, reload4j and logback. SLF4J allows the end-user to plug in the desired logging framework at deployment time. Note that SLF4J-enabling your library/application implies the addition of only a single mandatory dependency, namely slf4j-api-2.0.9.jar.
The idea is to build a logging event piece by piece with a LoggingEventBuilder and to log once the event is fully built. The atTrace(), atDebug(), atInfo(), atWarn() and atError() methods, all new in the org.slf4j.Logger interface, return an instance of LoggingEventBuilder. For disabled log levels, the returned LoggingEventBuilder instance does nothing, thus preserving the nanosecond level performance of the traditional logging interface.
The key-value pair variant of the API stores the key-value pairs as separates objects. The default implementation currently in the org.slf4j.Logger class prefixes key-value pairs to the message. Logging backends are free and are even encouraged to offer a more customizable behaviour.
To switch logging frameworks, just replace slf4j bindings on your class path. For example, to switch from java.util.logging to reload4j, just replace slf4j-jdk14-2.0.9.jar with slf4j-reload4j-2.0.9.jar.
since 2.0.9 You can specify the provider class explicitly via the "slf4j.provider" system property. This bypasses the service loader mechanism for finding providers and may shorten SLF4J initialization.
Authors of widely-distributed components and libraries may code against the SLF4J interface in order to avoid imposing a logging framework on their end-user. Thus, the end-user may choose the desired logging framework at deployment time by inserting the corresponding slf4j binding on the classpath, which may be changed later by replacing an existing binding with another on the class path and restarting the application. This approach has proven to be simple and very robust.
As of SLF4J version 1.6.0, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of throwing a NoClassDefFoundError because the org.slf4j.impl.StaticLoggerBinder class is missing, SLF4J version 1.6.0 and later will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. For example, let Wombat be some biology-related framework depending on SLF4J for logging. In order to avoid imposing a logging framework on the end-user, Wombat's distribution includes slf4j-api.jar but no binding. Even in the absence of any SLF4J binding on the class path, Wombat's distribution will still work out-of-the-box, and without requiring the end-user to download a binding from SLF4J's web-site. Only when the end-user decides to enable logging will she need to install the SLF4J binding corresponding to the logging framework chosen by her.
Basic rule Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding/provider but only depend on slf4j-api. When a library declares a transitive dependency on a specific binding, that binding is imposed on the end-user negating the purpose of SLF4J. Note that declaring a non-transitive dependency on a binding, for example for testing, does not affect the end-user.
SLF4J API SLF4J API ships within the "org.slf4j:slf4j-api" artifact. You can explicitly declare a dependency to it in your pom.xml file as shown below. Note that most logging implementations will automatically pull-in slf4j-api as a dependency. However, it is often a good idea to declare an explicit dependency to slf4j-api in order to fix the correct version of slf4j-api your project by virtue of of Maven's "nearest definition" dependency mediation rule.
logback-classic 1.3.x (Javax EE) If you wish to use logback-classic for Javax EE as the underlying logging framework, all you need to do is to declare "ch.qos.logback:logback-classic" as a dependency in your pom.xml file as shown below. In addition to logback-classic-1.3.6.jar, this will pull in slf4j-api-2.0.9.jar as well as logback-core-1.3.6.jar into your project. Note that explicitly declaring a dependency on logback-core-1.3.6 or slf4j-api-2.0.9.jar is not wrong and may be necessary to impose the correct version of said artifacts by virtue of Maven's "nearest definition" dependency mediation rule.
logback-classic 1.4.x (Jakarta EE) If you wish to use logback-classic for Jakarta EE as the underlying logging framework, all you need to do is to declare "ch.qos.logback:logback-classic" as a dependency in your pom.xml file as shown below. In addition to logback-classic-1.4.6.jar, this will pull in slf4j-api-2.0.9.jar as well as logback-core-1.4.6.jar into your project. Note that explicitly declaring a dependency on logback-core-1.4.6 or slf4j-api-2.0.9.jar is not wrong and may be necessary to impose the correct version of said artifacts by virtue of Maven's "nearest definition" dependency mediation rule.
reload4j If you wish to use reload4j as the underlying logging framework, all you need to do is to declare "org.slf4j:slf4j-reload4j" as a dependency in your pom.xml file as shown below. In addition to slf4j-reload4j-2.0.9.jar, this will pull in slf4j-api-2.0.9.jar as well as reload4j-1.2.25.jar into your project. Note that explicitly declaring a dependency on reload4j-1.2.25.jar or slf4j-api-2.0.9.jar is not wrong and may be necessary to impose the correct version of said artifacts by virtue of Maven's "nearest definition" dependency mediation rule.
java.util.logging If you wish to use java.util.logging as the underlying logging framework, all you need to do is to declare "org.slf4j:slf4j-jdk14" as a dependency in your pom.xml file as shown below. In addition to slf4j-jdk14-2.0.9.jar, this will pull in slf4j-api-2.0.9.jar into your project. Note that explicitly declaring a dependency on slf4j-api-2.0.9.jar is not wrong and may be necessary to impose the correct version of said artifact by virtue of Maven's "nearest definition" dependency mediation rule.
SLF4J Simple If you wish to use org.slf4j.simple as the underlying logging implementation, all you need to do is to declare "org.slf4j:slf4j-simple" as a dependency in your pom.xml file as shown below. In addition to slf4j-simple-2.0.9.jar, this will pull in slf4j-api-2.0.9.jar into your project. Note that explicitly declaring a dependency on slf4j-api-2.0.9.jar is not wrong and may be necessary to impose the correct version of said artifact by virtue of Maven's "nearest definition" dependency mediation rule.
An SLF4J provider/binding designates an artifact such as slf4j-jdk14.jar or slf4j-reload4j.jar used to bind slf4j to an underlying logging framework, say, java.util.logging and respectively reload4j.
Mixing different versions of slf4j-api.jar and SLF4J provider/binding can cause problems. For example, if you are using slf4j-api-2.0.9.jar, then you should also use slf4j-simple-2.0.9.jar, using slf4j-simple-1.5.5.jar will not work.
However, from the client's perspective the SLF4J API, more specifically classes in the org.slf4j package, are backward compatible for all versions. Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M. You only need to ensure that the version of your provider/binding matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used by a given dependency in your project. You can always use any version of slf4j-api.jar, and as long as the version of slf4j-api.jar and its provider/binding match, you should be fine.
The implementation of JCL over SLF4J, i.e jcl-over-slf4j.jar, will allow your project to migrate to SLF4J piecemeal, without breaking compatibility with existing software using JCL. Similarly, log4j-over-slf4j.jar and jul-to-slf4j modules will allow you to redirect log4j and respectively java.util.logging calls to SLF4J. See the page on Bridging legacy APIs for more details.
Note that SLF4J-enabling your library implies the addition of only a single mandatory dependency, namely slf4j-api.jar. If no binding/provider is found on the class path, then SLF4J will default to a no-operation implementation.
I'm attempting to upgrade from Hibernate 3.2 to 3.4, which apparently uses slf4j. Our project currently uses log4j. So my assumption is that I should be using the slf4j-log4j12 wrapped implementation.
After checking the version 1.5.6 POM for slf4j-log4j (and then slf4j-parent) you should be using log4j-1.2.14. The slf4j-log4j POM uses dependency management to inherit the appropriate version of log4j from the slf4j-parent POM.
As result, slf4j ignores the configuration and is no longer usable from within Eclipse with m2e installed.
If I start mvn test from a commandline, no such messages appear. slf4j logging is working as it should.
That message indicates that you are bringing in both logback-classic and log4j-slf4j-impl, which both want to be the logging framework for SLF4J to bind to. If you're not sure which dependency is bringing in which other dependencies, I find it very useful to run "mvn dependency:tree" to see the tree of dependencies being used. That should give you enough information to figure out which logging framework binding you need to exclude.
Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose. When you come across an embedded component declaring a compile-time dependency on any SLF4J binding, please take the time to contact the authors of said component/library and kindly ask them to mend their ways.
You pretty much want to exclude all actual logging frameworks from all dependencies, so that the only logging framework being used is the one you've explicitly added. I even often find it useful to set up some maven-enforcer-plugin bannedDependencies rules to ensure that I don't accidentally bring in another logging framework when updating my dependencies. It can also be helpful to use dependencyManagement sections in your POM to ensure that all your dependencies use the same version of slf4j-api.
760c119bf3