question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

org.slf4j v1.7.25 and v1.8.0-beta4 included

See original GitHub issue

When using your package using gradle on java 11 I get following error

Error:java: module org.pf4j reads package org.pf4j from both slf4j.api and org.slf4j

When checking the files gradle loads and downloads I see org.pf4j is the only one including old version and a new version at the same time of the org.slf4j version.

Screenshot 2019-09-25 at 18 18 02

I tested this both v2.6.0 and v3.1.0 both having the same affect. How can I not use org.slf4j v1.7.25 and exclude it during build / runtime?

Thanks for the help

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:10 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
Douglasdc3commented, Sep 26, 2019

Thanks @decebals you helped me dig down to the right package that was causing the issue

multiple packages are trying to claim slf4j implementation. jcl-over-slf4 (spring boot), logback and slf4j itself. I simplified the gradle file and it now only includes the slf4j api and spring boot adds a concrete logging framework.

Thanks for helping me discover this. I’m not that familiar with gradle either. You have a really easy and nice to use plugin module

0reactions
decebalscommented, Sep 26, 2019

As I said. I am not a Gradle connoisseur, but I feel that you are not interpreting the result correctly. I think that is similar with what is in Maven. So, ch.qos.logback:logback-classic has a direct dependency at org.slf4j:slf4j-api:1.8.0-beta1. The line org.slf4j:slf4j-api:1.7.25 -> 1.8.0-beta1 says that PF4J has slf4j-api:1.7.5 as dependency but Gradle will substitute this version with 1.8.0-beta1. Probably it’s the default strategy of how Gradle pick a version from multiple versions. If you remove ch.qos.logback:logback-classic than you will see (probably) that 1.8.0-beta1 will disappear.

But in the end I don’t know where is the problem if you go with 1.8.0-beta1 in your application.

Read more comments on GitHub >

github_iconTop Results From Across the Web

SLF4J News
October 1st, 2019 - Release of SLF4J 2.0.0-alpha1. • Refactored the fluent-api in org.slf4j.Logger interface to ease the work required by downstream ...
Read more >
org.slf4j » slf4j-api » 1.7.25 - Maven Repository
API for SLF4J (The Simple Logging Facade for Java) which serves as a simple facade or abstraction for various logging frameworks, ...
Read more >
org.slf4j (SLF4J API Module 1.7.25 API) - Javadoc.io
The LoggerFactory is a utility class producing Loggers for various logging APIs, most notably for log4j, logback and JDK 1.4 logging.
Read more >
org.slf4j:slf4j-ext - Snyk Vulnerability Database
version published direct vulnerabilities 2.0.5 25 Nov, 2022 0. C. 0. H. 0. M. 0. L 2.0.4 17 Nov, 2022 0. C. 0. H. 0....
Read more >
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder"
Hence apart from having slf4j you need to include any of your logging framework like log4j or logback (etc) in your classpath.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found