SLF4J: ścieżka klasy zawiera wiele powiązań SLF4J


206

Otrzymuję następujący błąd. Wygląda na to, że istnieje wiele ram rejestrowania powiązanych z sl4j. Nie wiesz, jak to rozwiązać. Każda pomoc jest mile widziana.

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/admin/.m2/repository/org/slf4j/slf4j-log4j12/1.6.4/slf4j-log4j12-1.6.4.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/admin/.m2/repository/org/slf4j/slf4j-log4j12/1.6.1/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

15
Rozwiązane Użycie <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions> w zależnościach (pom.xml), które spowodowały konflikt, pomogło rozwiązać problem
użytkownik1493140,


6
Czy sprawdziłeś już slf4j.org/codes.html#multiple_bindings zgodnie z ostrzeżeniem?
Peter Keller

7
Może lepiej byłoby dodać odpowiedź (automatyczną odpowiedź) do tego pytania i oznaczyć je jako „Zaakceptowane”, więc pytanie pojawi się jako „Rozwiązane” w wyszukiwaniu SO
Roberto

1
Roberto, dziękuję za opinię. Skopiowałem rozwiązanie z komentarza i opublikowałem jako odpowiedź.
user1493140,

Odpowiedzi:


125

Rozwiązany przez dodanie następującego wyłączenia w zależnościach (pom.xml), które spowodowały konflikt.

<exclusions>
    <exclusion>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
    </exclusion>
</exclusions> 

10
która zależność spowodowała konflikt w tym przypadku, mam drzewo zależności istnieją 3 wzmianki o slf4j
PUG

22
aby dowiedzieć się, jak log4j trafia na ścieżkę uzależnienia run mvn: drzewa i przeczesać, następnie dodać fragment powyżej tej zależności w pom.xml
cyber mnicha

1
@ user1493140 Nadal dla mnie to nie działa. <dependency> <groupId> log4j </groupId> <artifactId> log4j </artifactId> <version> 1.2.17 </version> <exkluzja> <wykluczenie> <groupId> org.slf4j </groupId> <artifactId> slf4j- log4j12 </artifactId> </exclusion> </exclusion> </dependency>
Ashok kumar Ganesan

1
dla mnie kolejną przyczyną wojny. Musiałem wykluczyć artefakty o identyfikatorach slf4j-nop i slf4j-jdk14. Zależność, która spowodowała konflikt był dla mnie koniczyna-Maven-plugin
ihebiheb

czy wersja ( slf4j-log4j12) ma zastosowanie do wszystkich? czy powinniśmy znaleźć wersję z zależności mvn: drzewo ?
Lei Yang,

59

Wersja stopniowa;

configurations.all {
    exclude module: 'slf4j-log4j12'
}

2
Importowanie modeli z głównej aplikacji do środowiska automatyzacji. To rozwiązało mój problem z gradle. ty.
Czy

1
Czy jest jakaś wersja mrówki?
Balaji Boggaram Ramanarayan

1
no: ant nie jest narzędziem uwzględniającym zależności. Zdecydowanie rozważ przeniesienie kompilacji do gradacji.
Matthew Mark Miller,

1
zdecydowanie
zalecamy

2
Doskonały. Uratował mnie od kilku godzin piekła uzależnienia!
jeseals

24

Błąd prawdopodobnie daje więcej takich informacji (chociaż nazwy słoików mogą być inne)

SLF4J: Znaleziono powiązanie w [jar: file: / D: /Java/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar! / Org / slf4j / impl / StaticLoggerBinder .class] SLF4J: Znaleziono powiązanie w [jar: file: / D: /Java/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.8.2/log4j-slf4j-impl-2.8.2.jar ! /org/slf4j/impl/StaticLoggerBinder.class]

Zauważyłem, że konflikt pochodzi z dwóch słoików o nazwach logback-classic-1.2.3i log4j-slf4j-impl-2.8.2.jar.

Uruchom mvn dependency:treew tym projekcie folder nadrzędny pom.xml, podając:

konflikt drzewa zależności

Teraz wybierz ten, który chcesz zignorować (może pochłonąć delikatne przedsięwzięcie, potrzebuję w tym więcej pomocy)

Postanowiłem nie korzystać z jednego z importowaną spring-boot-starter-data-jpa(zależność TOP) poprzez spring-boot-starteri dzięki spring-boot-starter-logging, POM staje się:

    <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>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>

powyżej pom spring-boot-starter-data-jpaużyłby spring-boot-starterskonfigurowanego w tym samym pliku, co wyklucza logging(zawiera logback)


1
Dziękujemy za wprowadzenie mvn dependency:tree. Jest to bardzo pomocne ...
Jan Lochman,

10

Wersja SBT:

Dołącz exclude("org.slf4j", "slf4j-log4j12")do zależności, która obejmuje tranzytowo slf4j-log4j12. Na przykład podczas korzystania z Spark z Log4j 2.6:

libraryDependencies ++= Seq(
  // One SLF4J implementation (log4j-slf4j-impl) is here:
  "org.apache.logging.log4j" % "log4j-api" % "2.6.1",
  "org.apache.logging.log4j" % "log4j-core" % "2.6.1",
  "org.apache.logging.log4j" % "log4j-slf4j-impl" % "2.6.1",
  // The other implementation (slf4j-log4j12) would be transitively
  // included by Spark. Prevent that with exclude().
  "org.apache.spark" %% "spark-core" % "1.5.1" exclude("org.slf4j", "slf4j-log4j12")
)

1
Co oznacza skrót Sbt?
Petrus Theron

3
Proste narzędzie do kompilacji *
Benny

4
<!--<dependency>-->
     <!--<groupId>org.springframework.boot</groupId>-->
     <!--<artifactId>spring-boot-starter-log4j2</artifactId>-->
<!--</dependency>-->

Rozwiązałem, usuwając to: spring-boot-starter-log4j2


nie jasne: czy masz na myśli usunięcie / komentarz powyżej sekcji xml, czy dodanie?
Lei Yang,


3

Wystarczy użyć tylko wymaganej zależności, nie wszystkich :))). Dla mnie do normalnej pracy procesu rejestrowania potrzebna jest ta zależność, wyklucz inne z pom.xml

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

    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>1.1.8</version>
    </dependency>

    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-core</artifactId>
        <version>1.1.8</version>
    </dependency>

3

Jest to problem, ponieważ klasa StaticLoggerBinder.class należy do dwóch różnych słoików. ta klasa odwołuje się do logback-classic-1.2.3.jar i ta sama klasa odwołuje się również z log4j-slf4j-impl-2.10.0.jar. oba słoiki w ścieżce klas. Stąd między nimi jest konflikt. Z tego powodu plik dziennika nie jest generowany, mimo że plik log4j2.xml w ścieżce klasy [src / main / resource].

Mamy więc jeden ze słoików, zalecam użycie pliku log4j-slf4j-impl-2.10.0.jar i wykluczenie pliku logback-classic-1.2.3.jar. Rozwiązanie: otwórz plik pom i wyświetl hierarchię zależności [zaćmienie] lub uruchom polecenie
mvn dependency: tree, aby znaleźć drzewo zależności i źródło zależności, które pobierają zależność. znajdź sprzeczną zależność i wyklucz je. W przypadku aplikacji Springboot spróbuj tego.

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</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-actuator</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

This is working fine for me after struggling a lots.

2

... org.codehaus.mojo cobertura-maven-plugin 2.7 test ch.qos.logback logback-classic narzędzia com.sun ...

## Naprawiłem to

... org.codehaus.mojo cobertura-maven-plugin 2.7 test ch.qos.logback logback-classic narzędzia com.sun ...


2

Dla mnie okazało się to problemem Eclipse / Maven po zmianie z log4j na logback. Przejrzyj swój .classpathplik i wyszukaj ciąg "log4j".

W moim przypadku miałem tam następujące: <classpathentry kind="var" path="M2_REPO/org/slf4j/slf4j-log4j12/1.7.1/slf4j-log4j12-1.7.1.jar"/> <classpathentry kind="var" path="M2_REPO/log4j/log4j/1.2.17/log4j-1.2.17.jar" />

Usunięcie tych wpisów z pliku (lub można je ponownie wygenerować) rozwiązało problem.


2

Dla mnie odpowiedzią było wymuszenie odbudowy Maven. W środowisku Eclipse:

  1. Kliknij prawym przyciskiem myszy projekt-> Maven -> Wyłącz naturę Maven
  2. Kliknij prawym przyciskiem myszy projekt-> Narzędzia wiosny> Zaktualizuj zależności Maven
  3. Kliknij prawym przyciskiem myszy projekt-> Konfiguruj> Konwertuj projekt Maven

0

Miałem ten sam problem. W moim pom.xml miałem oba

 <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-simple</artifactId>
        <version>1.7.28</version>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.2.1.RELEASE</version>
    </dependency>

Kiedy usunąłem zależność Spring-Boot-Starter-Web, problem został rozwiązany.


-1

Połączenie <scope>provided</scope>i<exclusions> nie działało dla mnie.

Musiałem użyć tego:

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <scope>system</scope>
    <systemPath>${project.basedir}/empty.jar</systemPath>
</dependency>

Gdzie empty.jarjest plik jar z dosłownie niczym.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.