eclipse: java: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" or Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder

 

>PROBLEM

Using Eclipse, you try to run a simple logging test using "org.slf4j.Logger" like the sample below:

package Test;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Test {

    private static final Logger LOGGER = LoggerFactory.getLogger(Test.class);

    public static void main(String[] args) {

        LOGGER.info("done");

    }

}

Unfortunately, it fails to return the following message:

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#StaticLoggerBinder for further details.

or:

Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder

>SOLUTION

1. Check your slf4j jars.

First, make sure that you have the correct dependency jars.

For instance:

  slf4j-api-2.0.13.jar
  slf4j-simple-2.0.13.jar

More information:

https://www.slf4j.org/codes.html#StaticLoggerBinder

https://www.slf4j.org/faq.html#changesInVersion200

2. Check the Eclipse's ".classpath" file.

Edit it to find if there is some inconsistency with your lib, like references that differ in content.
It is rare but it may happen.

Make a copy of it (backup).
Edit it, and try to find old references to other conflicting jars.
Example of old entry not automatically removed by Eclipse:

    <classpathentry kind="lib" path="lib/log4j-1.2.15.jar"/>

You also may get the ".classpath" from another and similar project that works well, remove the unnecessary entries and insert the missing ones.

On Eclipse, close the project that you are fixing, replace it with the new ".classpath" file, and reopen the project.

Test it again.

3. Check the project libs searching for one that already provides the slf4j.

If a lib already contains the slf4j, its version may conflict with the slf4j's jars.

A simple way to check if the project has a lib that already contains slf4j is to remove the explicit slf4j jars from the project.

If the "import" to slf4j still works, not alarming that it misses the slf4j lib, then one of your jars is offering it.

For instance, the "apacheds-all" lib (apacheds-all-1.5.5.jar, apacheds-all-2.0.0.AM27.jar).

By the way...

"ApacheDS is an embeddable directory server entirely written in Java, which has been certified LDAPv3 compatible by the Open Group. Besides LDAP it supports Kerberos 5 and the Change Password Protocol. It has been designed to introduce triggers, stored procedures, queues and views to the world of LDAP which has lacked these rich constructs."

To discover which lib already contains the slf4j lib, you may create another project without lib (empty). The project will have just one class that uses slf4j like the example above (Test class).

Delete the jar files, all of them.
Update the project and check if the import is not working.
OK, if not, the test is successful.

Now add some jars and update the project.
Check again if the import is not resolving.
If it is, good! It means that there isn't a lib offering the slf4j.
Repeat this cycle adding other libs until the import is resolved.
There you go! Isolate the jar file that resolves the slf4j import and you have discovered the conflict.

>ENV

java
eclipse