Class path contains multiple SLF4J bindings - java

I tried to debug my project but got this
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/usr/local/storm/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/user/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
what should i do ?
i haven't any dependency for SLF4J in POM just this
<dependency>
<groupId>org.apache.storm</groupId>
<artifactId>storm-core</artifactId>
<version>0.9.6</version>
<scope>provided</scope>
</dependency>
i tried to use the solutions i found in similar posts but didn't solve it ! like
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
<exclusion>
<groupId>logback-classic</groupId>
<artifactId>ch.qos.logback</artifactId>
</exclusion>
</exclusions>
I tried to replace provided to compile but didn't solve it too .
I got this with using mvn dependency:tree
org.slf4j:log4j-over-slf4j:jar:1.6.6:provided
org.slf4j:slf4j-api:jar:1.7.5:compile

You have 2 sources of dependencies for storm one from /usr/local/storm/lib/ directory and the second from maven which cause multiple binding for sl4j.
Try using just one source of dependencies.

Following the line of the accepted answer, the way i found to try using just one source of dependencies, was to clone/create again the project i was working on. In my case was an already started project and probably due to poor connection speed, i had a few issues re importing all Maven Projects. So i messed up a bit with the project's settings trying to access all the propper dependencies.
That caused some unexpected changes on my project's pom.xml file that leaded to the error. So, cloning again de project to a new folder and making the maven re import with some decent internet speed just worked fine for me.
Hope to be helpful. Regards

Related

why is my maven sub dependency version for spark connector package different from others

I am trying to use a pom file from a existing project and I am getting an error "Cannot resolve org.yaml:snakeyaml:1.15"
What I find out about this error is that the com.datastax.spark:spark-cassandra-connector_2.11:2.5.0 uses a couple dependencies and a couple levels down it is using snakeyaml:1.15 which is quarantined by company proxy. Is there a way to specify for a given maven dependency that I want to use snakeyaml:1.16?
One thing I do not understand is that I look into the reference project that is also using com.datastax.spark:spark-cassandra-connector_2.11:2.5.0, it is using the updated com.datastax.oss:java-driver-core-shaded:4.9.0, which no longer requires snakeyaml:1.15
where as mine uses the old com.datastax.oss:java-driver-core-shaded:4.5.0
Why is it working in that pom? we have the same maven listing version for com.datastax.spark:spark-cassandra-connector_2.11:2.5.0
I see it has some exclusions but none addresses the snake yaml version or any of its parent dependencies.
Is there another section of the pom file that addresses this I am missing? please advise.
My pom
<scala.compat.version>2.11</scala.compat.version>
<spark.cassandra.version>2.5.0</spark.cassandra.version>
<dependency>
<groupId>com.datastax.spark</groupId>
<artifactId>spark-cassandra-connector_${scala.compat.version}</artifactId>
<version>${spark.cassandra.version}</version>
</dependency>
where it goes wrong
however another project is using the correct shaded version com.datastax.oss:java-driver-core-shaded:4.9.0, which eliminates the snake dependency
working pom
<scala.compat.version>2.11</scala.compat.version>
<spark.cassandra.version>2.5.0</spark.cassandra.version>
<dependency>
<artifactId>spark-cassandra-connector_${scala.compat.version}</artifactId>
<exclusions>
<exclusion>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</exclusion>
<exclusion>
<artifactId>netty-all</artifactId>
<groupId>io.netty</groupId>
</exclusion>
<exclusion>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
</exclusion>
</exclusions>
<groupId>com.datastax.spark</groupId>
<version>${spark.cassandra.version}</version>
</dependency>
You add an entry your <dependencyManagement> section of your POM, where you specify the version of snakeyaml that you want.
This will override all transitive version definitions of snakeyaml.
I suggest to switch to the SCC 2.5.2 (or at least 2.5.1) - there were fixes there regarding dependencies, it has driver upgraded to 4.10.0, etc. Another possibility is to use spark-cassandra-connector-assembly instead, with all dependencies included & shaded.

spring-security-core conflicting version issue in build tree

I am trying to install spring-security-core to my project and here's how I am doing it in my pom.xml
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-core</artifactId>
<version>5.0.7.RELEASE</version>
</dependency>
The issue is that when I build the project I see org.springframework.security.spring-security-core with version 4.2.9.RELEASE in my artifacts instead of 5.0.7.RELEASE. My pom.xml is deep down in my build tree and it's a part of a big spring boot project. artifact spring-security-core is not present in any other pom.xml in my tree.
From what I've read so far it looks like this is happening because something in the parent tree is downloading spring-security-core 4.2.9.RELEASE as a dependency without explicitly mentioning it in their pom.xml. How to debug this problem ?
In one of the parent pom.xml there's a dependency like this :
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>4.3.22.RELEASE</version>
</dependency>
Would that explain why spring-security-core old version is getting downloaded ? Any help is appreciated.
Check the dependency tree with this command
mvn dependency:tree
If spring-context-support also has spring-security, you can exclude that from the dependency by adding exclusions
example
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>4.3.22.RELEASE</version>
<exclusions>
<exclusion>
<groupId> groupid of the jar to be excluded </groupId>
<artifactId>artifact id of the jar to be excluded</artifactId>
</exclusion>
</exclusions>
</dependency>
Go to the location of parent pom.xml file and as run the command
mvn dependency:tree >> tree.txt
It will create a file with dependency tree. Search for "spring-security-core" you will find which version is downloaded.
There are couple of work around:
You can repeat this to each pom.xml as well to know from where it gets the reference.
If one of the pom referring the version then your dependency will not consider if its got resolve earlier.
Check if any po.xml file referring to any spring security related libraries. If so, what is there version. And if you need then as mentioned by #Vinay, exclude it so your library version gets referred.
If you want to download this version of library then mentioned it at the top, so it gets referred and no other version will downloaded.
There is no relation for spring security with spring-context-code. Refer this maven link.

SLF4J Logback LoggerContext Conflicts

I am working on deploying a spring boot executable jar for my application. Im using SLF4J logging, and when I build and run inside of IntelliJ I have no issues.
However, when I try to run the .jar, from the command line I get a LoggerFactory is not a Logback LoggerContext but Logback is on the classpath exception.
It complains about the slf4j-log4j12-1.7.12.jar in two places /opt/mapr/lib/ and /opt/mapr/hadoop/hadoop-2.7.0/share/hadoop/common/lib/.
If i remove the jar from both places and run my app:
java -cp $(mapr classpath):MapRProducerApp-0.0.1-SNAPSHOT.jar org.springframework.boot.loader.PropertiesLauncher
it will then fail startup due to SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
I dont understand why it would fail saying faild to load the slf4j class when my apps .jar is built with that dependency through
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
In IntelliJ, I am bringing in all external dependencies that exist inside the /opt/mapr/lib folder, which includes the slf4j-log4j12-1.7.10.jar, but IntelliJ does not give the Logback LoggerContext error.
To recap here:
Building and running the jar on its own works, but will fail because it needs dependencies that exist inside the mapr classpath.
Running the jar with the mapr classpath fails because of the slf4j jar inside /opt/mapr/lib.
Removing that jar leads to another failure about a slf4j jar in /opt/mapr/hadoop/hadoop-2.7.0/share/hadoop/common/lib/.
Removing that jar then fails the app because it now cannot find any slf4j binding.
Is there something im missing? Do I need to package my app a certain way so it does not include the SLF4J dependency?
I'm not clear about your <dependencies> hierarchy, but by adding <exclusion> you can simply resolve the conflict.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
If you are using Spring-boot actuator, only exclusion of spring-logging might not help.
You will have to provide logging for it. Spring Boot support log4j for logging configuration.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>
Refrence: https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.logging

SLF4J + version 1.7.x by your slf4j binding is not compatible 1.6 [duplicate]

I realised that one of my projects uses slf4j 1.5.8 and Hibernate uses slf4j 1.6. While building with Maven it downloads both jars but I guess the class files of 1.5.8 are used. So, when I run the program i get following error:
SLF4J: The requested version 1.5.8 by your slf4j binding is not compatible with [1.6]
In pom.xml I have put
<dependencyManagement>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.1</version>
</dependency>
</dependencyManagement>
The 1.5.8 is part of dependency so it's downloaded on its own.
As you discovered yourself, there are two libraries (Hibernate and some other) transitively importing SLF4J in two different versions. Unfortunately the older version is being picked up by maven (there are some rules which dependency should be chosen by maven in this situation). The solution is to add the exclusion in the dependency that imports older version of SLF4J (com.example:foo-bar is example here):
<dependency>
<groupId>com.example</groupId>
<artifactId>foo-bar</artifactId>
<version>1.2.3</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>
If you still experience this problem, issue:
$ mvn dependency:tree
Look for 1.5.8 version and exclude it from all libraries importing it.
Excluding is quite unnecessary and maybe quite misleading. Instead, explicitly include the slf4j-api with the desired version in your projects pom file. That's it!
This approach takes advantage of Maven's transitivity rules: the nearest dependency declaration wins.
you can exclude the wrong version with something like this:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.2.7.ga</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>

How to exclude jar that contains StaticLoggerBinder from activemq-all maven dependency?

I'm using ActiveMQ (an apache camel component) to send SMS from web to GSM mobile, so I needed to use SLF4J.
I got this in the output of my netbeans project when i run it
it seems like the jar is present two times, and i think that i need to add an exclusion in the dependency in my pom.xml but i dont know what to do exactly !
This is the part of SLF4 in my pom.xml:
<!-- logging -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.5</version>
<!-- <exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
</exclusions> -->
</dependency>
And this is my output while running my project
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/asus/.m2/repository/org/apache/activemq/activemq-all/5.9.0/activemq-all-5.9.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/asus/.m2/repository/org/slf4j/slf4j-log4j12/1.7.5/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
Try the following:
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-all</artifactId>
<version>5.9.0</version>
<type>pom</type>
</dependency>
See more in [AMQ-5009] Switch activemq-all from shaded jar to pom dependency aggregator - ASF JIRA.
Your question is lacking a bit of context, but I'd say you should simply drop that slf4j-log4j12 dependency from your POM, since an SLF4J binding is embedded in activemq-all-5.9.0.jar anyway.
Or maybe you could try not using activemq-all with embedded dependencies and use individual ActiveMQ artifacts with ordinary transitive dependencies.
I agree with not using activemq-all, instead using the individual dependencies you need. In general I've found that using '-all' dependencies can create problems. Typically these repackage other dependencies where the normal Maven dependency resolution process can't get at them. Then, if you need to use a later version of an embedded dependency, problems result, and it's tricky/time-consuming to track down.
(Making this comment an answer per #bmargulies request.)

Categories

Resources