Download Slf4j-api

[Jorunn Collet]

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.

So, stick with your newer version of slf4j-api and just ensure you declare a binding as a dependency, e.g. slf4j-jdk14. If you are producing a library, ensure your binding is declared with test scope only.

download slf4j-api

Download Zip ☆☆☆ https://shurll.com/2zD6Ng

The output of mvn dependency:tree clearly shows that both slf4j-api and slf4j-simple are on your class path. The fact that SLF4J complains about not finding org.slf4j.impl.StaticLoggerBinder means that there is another copy of slf4j-api.jar somewhere on your classpath and this is the copy being loaded into memory (rather than the copy of slf4j-api.jar in com.nike.dpt:dpt:war). Under such circumstances, because of the class loader delegation model of many application servers, the classes loaded by the server's copy of slf4j-api cannot find the classes packaged in slf4j-simple.jar located in your web-app. Typically this occurs when a copy of slf4j-api.jar is placed in the application server's lib/ folder as opposed to the WEB-INF/lib/ folder of your web-application.

It very much looks like the version of slf4j-api.jar being loaded by the JVM has version 1.5.x. You surely have slf4j-api-1.5.x.jar on your class path (in addition to slf4j-api-1.6.2.jar). Check your class path.

Mixing different versions of slf4j-api.jar and SLF4J binding can cause problems. For example, if you are using slf4j-api-1.7.2.jar, then you should also use slf4j-simple-1.7.2.jar, using slf4j-simple-1.5.5.jar will not work.

NOTE From the client's perspective all versions of slf4j-api are compatible. 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 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 binding match, you should be fine.

Also, you must have a many slf4j-api jars of versions mentioned in the []. Try keeping a single version of slf4j-api and the corresponding compatible slf4j-log4j jars in the classpath.

The tutorial video shows that 3 of the jar files are used (log4j-over-slf4j, slf4j-api & slf4j-log4j12) but if I add all 3 of them to the build path of my project (I'm not using Maven!), it complains that both "log4j-over..." and the api are there.

Using slf4j-api in code is normal, but you still want to control logging output. Using JBoss makes this hard. Fiddling with standalone config in CI env is also hard compared to adding an XML file to each EAR.

Well slf4j is a logging facade. It has no concept of appenders. WildFly supplies an slf4j binding which binds to the JBoss Log Manager. If you want to use your own log manager it's quite easy to just exclude the logging subsystem. You then just need to include an slf4j-api library and a binder in your deployment.

To enable SLF4J in your project you need to include the slf4j-api library and logging framework of your choice. For the purpose of this blog post, we will also include the slf4j-simple library, so that we can show how the SLF4J API looks in an easy way without complicating it with additional logging framework configuration. The slf4j-simple results in the SLF4J facade printing all log messages with INFO level or above to be printed in the System.err. Because of that, our Gradle build.gradle file looks as follows (you can find the whole project on Sematext Github account):

For SLF4J to be able to work with a logging framework of your choice in addition to the slf4j-api library you need to choose the appropriate bindings dedicated to your logging framework.

It is also a good practice for the libraries and embedded software to only include dependency to the slf4j-api library and nothing else. That way the binding will be chosen by the developer of the application that uses the library.

The recommended way for an application bundle to use the SLF4J logging API is to import the package org.slf4j in the bundle's manifest. If using Maven, then declaring a dependency on org.slf4j/slf4j-api/1.6.2 will be all that is required. Fuse provides an implementation of SLF4J which will link automatically to the API.

A more common choice amongst SLF4J users, which uses fewer step sand generates fewer dependencies, is to bind directly to Logback. This removes the extra binding step because Logback implements SLF4J directly, so you only need to depend on two libaries not four (jcl-over-slf4j and logback). If you do that you might also need to exclude the slf4j-api dependency from other external dependencies (not Spring), because you only want one version of that API on the classpath.

TRANSITIVITY Note that in addition to logback-classic.jar, the above declaration will automatically pull-in slf4j-api.jar and logback-core.jar into your project by virtue of Maven's transitivity rules.

• com.atlassian.maven.plugins:jarjar-maven-plugin:maven-plugin
  • org.codehaus.groovy.maven:gmaven-mojo:jar
    • org.codehaus.groovy.maven.runtime:gmaven-runtime-default:jar
      • org.codehaus.groovy.maven.runtime:gmaven-runtime-1.5:jar
        • org.codehaus.groovy.maven.runtime:gmaven-runtime-support:jar
          • org.slf4j:slf4j-api:jar
          • org.codehaus.groovy.maven.runtime:gmaven-runtime-api:jar
          • org.codehaus.groovy.maven.feature:gmaven-feature-support:jar
          • com.thoughtworks.qdox:qdox:jar

This warning, i.e. not an error, message is reported when no SLF4J
providers could be found on the class path. Placing one (and only one)
of slf4j-nop.jar slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar
or logback-classic.jar on the class path should solve the problem.
Note that these providers must target slf4j-api 1.8 or later.

If you are responsible for packaging an application and do not care
about logging, then placing slf4j-nop.jar on the class path of your
application will get rid of this warning message. Note that embedded
components such as libraries or frameworks should not declare a
dependency on any SLF4J providers but only depend on slf4j-api. When a
library declares a compile-time dependency on a SLF4J provider, it
imposes that provider on the end-user, thus negating SLF4J's purpose.

760c119bf3