Exception thrown while using logback/slf4j

Question

I am using slf4j 1.6.2 api jar (tried using 1.6.1 as well) - logback version is 0.9.29 (core & classic). I am using jdk1.6 on ubuntu. The exception I received is copied below.

Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.arrayFormat(Ljava/lang/String;[Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
    at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:112)
    at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:471)
    at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:427)
    at ch.qos.logback.classic.Logger.info(Logger.java:631)

I am also getting a message complaining about slf4j binding mismatch.

"SLF4J: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11]"

It looks like logback 0.9.29 depends on slf4j 1.6.1. Did you clean up your environment when you switched to 1.6.1? — Jeremy, Aug 23 '11 at 20:16
Has this issue been resolved? I am facing similar issue -rw-r--r-- slf4j-api.jar slf4j-api-1.6.4.jar slf4j-log4j12-1.6.4.jar.. I have below jars in WebSphere Lib.. — Nayeem, Jun 30 '14 at 08:43

Ceki · Answer 1 · 2012-06-12T13:56:56.803

26

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.

edited Jun 12 '12 at 13:56

answered Aug 23 '11 at 20:19

Ceki

26,753
7
62
71

8

Most often, it comes from a dependency of a dependency, ... Use `mvn dependency:tree` to check the dependencies – poussma Jan 08 '13 at 13:23
This gave me a hint, the product I am using bundled up newer version of SLF4J and hence my older version of SLF4J lib was causing this error. If you use Eclipse (ctrl+shift+T) or in JetBrains (Shift+Shift) and search for the Type (SLF4J) it will show all libraries containing file, remove the one that is not required. Hope this helps others. – MG Developer Nov 09 '18 at 16:36

score 11 · Answer 2 · answered Jul 16 '14 at 09:58

Adding the following dependencies might help :

  <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.7</version>
  </dependency>

  <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>jul-to-slf4j</artifactId>
      <version>1.7.7</version>
  </dependency>

  <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>jcl-over-slf4j</artifactId>
      <version>1.7.7</version>
  </dependency>

  <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>log4j-over-slf4j</artifactId>
      <version>1.7.7</version>
  </dependency>

  <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-jdk14</artifactId>
      <version>1.7.7</version>
  </dependency>

Finally after 5-6 hours of googling my issue is fixed. Thanks Trisha. — Wolfgang, Jul 29 '20 at 18:05

score 9 · Answer 3 · edited Oct 07 '15 at 20:17

slf4j-api version does not match that of the binding:

An SLF4J binding designates an artifact such as slf4j-jdk14.jar or slf4j-log4j12.jar used to bind slf4j to an underlying logging framework, say, java.util.logging and respectively log4j.

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.

At initialization time, if SLF4J suspects that there may be a api vs. binding version mismatch problem, it will emit a warning about the suspected mismatch.

Got from http://www.slf4j.org, I hope it can help.

score 1 · Answer 4 · answered Oct 12 '16 at 17:09

We have to align the versions of slf4j-api and the corresponding binding, in my case I was using slf4j-log4j12, acording with the documentation of SLF4J:

http://www.slf4j.org/codes.html#version_mismatch

I replace the versions of both libraries included as transitive dependencies, putting in my pom this:

    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.7.1</version>
    </dependency>

    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
        <version>1.7.1</version>
    </dependency>

I hope this help to somebody.

Kind regards,

Jaider

score 1 · Answer 5 · answered Aug 28 '11 at 09:15

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.

Mixing different versions of slf4j jars will always be troublesome

The NoSuchMethodError is due to the discovery of Methods-with-the-same-name more than once, probably coming from the different versions of the same jars

score 0 · Answer 6 · answered May 25 '16 at 08:11

0

I had the exact same error message. I solved it by excluding the dependency org.apache.directory.server:apacheds-all. Somehow that jar overrides org.slf4j.spi.LocationAwareLogger

answered May 25 '16 at 08:11

jvwilge

2,474
2
16
21

score 0 · Answer 7 · answered Aug 18 '17 at 22:28

This may be more "me too", but I'll try to outline a more complete solution. I mix a lot of software from diverse sources together in my product. I encountered this problem first with NiFi JARs, then more recently with Cassandra JARs all over again. I had already insisted in pom.xml that I have the same version of slf4j everywhere:

<slf4j.version>[1.7.25]</slf4j.version>
...
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>${slf4j.version}</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-simple</artifactId>
  <version>${slf4j.version}</version>
</dependency>
... (all the slf4j JARs I needed)

Then, I told Maven I wanted Cassandra without whatever it was bringing in for slf4j:

<dependency>
  <groupId>org.apache.cassandra</groupId>
  <artifactId>cassandra-all</artifactId>
  <version>${cassandra.version}</version>
  <exclusions>
    <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-simple</artifactId>
    </exclusion>
</dependency>

However, like you, I was getting complaints from

Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.arrayFormat(Ljava/lang/String;[Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
  at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:112)

From mvn dependency:tree, I found out that I was getting logback 1.1.3 which wasn't matching what Cassandra was apparently using (0.9-something like you). So, I excluded getting logback too by adding these exclusions to slf4j ones already there:

<dependency>
  <groupId>org.apache.cassandra</groupId>
  <artifactId>cassandra-all</artifactId>
  <version>${cassandra.version}</version>
  <exclusions>
    <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-simple</artifactId>
    </exclusion>
    <exclusion>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-core</artifactId>
    </exclusion>
    <exclusion>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
    </exclusion>
</dependency>

...whereupon, the problem I had and you are reporting here, went away. I hope this helps someone.

score 0 · Answer 8 · answered Jun 30 '20 at 19:27

0

Download from Below link

https://jar-download.com/artifacts/ch.qos.logback/logback-classic/1.1.3/source-code

all three jars are compatible with each other

answered Jun 30 '20 at 19:27

Narendra Ingle

1
3

Exception thrown while using logback/slf4j

8 Answers8

Linked

Related