streamalism.org

1. Oversigt

Når vi bruger SLF4J i vores applikationer, ser vi nogle gange en advarselsmeddelelse om flere bindinger i klassestien, der er trykt på konsollen.

I denne vejledning prøver vi at forstå, hvorfor vi ser denne meddelelse, og hvordan vi løser den.

2. Forståelse af advarslen

Lad os først se på en prøveadvarsel:

SLF4J: Klassesti indeholder flere SLF4J-bindinger. SLF4J: Fundet binding i [jar: file: ... / slf4j-log4j12-1.7.21.jar! /Org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Fundet binding i [jar: file: ... / logback -classic-1.1.7.jar! /org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Se //www.slf4j.org/codes.html#multiple_bindings for en forklaring. SLF4J: Faktisk binding er af typen [org.slf4j.impl.Log4jLoggerFactory]

Denne advarsel fortæller os, at SLF4J har fundet to bindinger. Man er inde slf4j-log4j12-1.7.21.jar og den anden i logback-classic-1.1.7.jar.

Lad os nu forstå, hvorfor vi ser denne advarsel.

Simple Logging Facade til Java (SLF4J) fungerer som en enkel facade eller abstraktion til forskellige logningsrammer. Således tillader det os at tilslutte vores ønskede logningsramme ved implementeringstidspunktet.

For at opnå dette ser SLF4J efter bindinger (alias udbydere) på klassestien. Bindinger er grundlæggende implementeringer af en bestemt SLF4J-klasse beregnet til at blive udvidet til at tilslutte en bestemt logningsramme.

Efter design binder SLF4J kun med en logningsramme ad gangen. Følgelig, hvis der er mere end en binding på klassestien, udsender den en advarsel.

Det er værd at bemærke, at indlejrede komponenter såsom biblioteker eller rammer aldrig bør erklære en afhængighed af nogen SLF4J-binding. Dette skyldes, at når et bibliotek erklærer en kompileringstidsafhængighed af en SLF4J-binding, pålægger den denne binding for slutbrugeren. Det er klart, at dette negerer SLF4Js grundlæggende formål. Derfor bør de kun afhænge af slf4j-api bibliotek.

Det er også vigtigt at bemærk, at dette kun er en advarsel. Hvis SLF4J finder flere bindinger, vælger den en logningsramme fra listen og binder med den. Som det kan ses på den sidste linje i advarslen, har SLF4J valgt Log4j ved hjælp af org.slf4j.impl.Log4jLoggerFactory til selve bindingen.

3. Find de modstridende JAR'er

Advarslen viser placeringen af ​​alle de bindinger, den finder. Normalt er dette tilstrækkelig information til at identificere den skruppelløse afhængighed, der transitivt trækker en uønsket SLF4J-binding ind i vores projekt.

Hvis det ikke er muligt at identificere afhængigheden af ​​advarslen, kan vi bruge afhængighed: træ maven mål:

mvn afhængighed: træ

Dette viser afhængighedstræet for projektet:

[INFO] + - org.docx4j: docx4j: jar: 3.3.5: kompilér [INFO] | + - org.slf4j: slf4j-log4j12: jar: 1.7.21: kompilere [INFO] | + - log4j: log4j: jar: 1.2.17: kompilere [INFO] + - ch.qos.logback: logback-classic: jar: 1.1.7: kompilere [INFO] + - ch.qos.logback: logback-core: jar: 1.1.7: kompilere 

Vi bruger Logback til at logge ind i vores applikation. Derfor har vi tilføjet Logback-bindingen, der er til stede i logback-klassiker JAR, bevidst. Men docx4j afhængighed har også trukket en anden binding med slf4j-log4j12 KRUKKE.

4. Opløsning

Nu hvor vi kender den fornærmende afhængighed, er alt, hvad vi skal gøre, at udelukke slf4j-log4j12 JAR fra docx4j afhængighed:

 org.docx4j docx4j $ {docx4j.version} org.slf4j slf4j-log4j12 log4j log4j 

Da vi ikke bruger Log4j, kan det også være en god ide at udelukke det.

5. Konklusion

I denne artikel så vi, hvordan vi kan løse den ofte viste advarsel om flere bindinger, der udsendes af SLF4J.

Kildekoden, der ledsager denne artikel, er tilgængelig på GitHub.