streamalism.org

1. Oversikt

Når vi bruker SLF4J i applikasjonene våre, ser vi noen ganger en advarsel om flere bindinger i klassestien som er skrevet ut til konsollen.

I denne opplæringen vil vi prøve å forstå hvorfor vi ser denne meldingen og hvordan vi kan løse den.

2. Forstå advarselen

La oss først se på et eksempel på advarsel:

SLF4J: Klassebane inneholder flere SLF4J-bindinger. SLF4J: Fant binding i [jar: file: ... / slf4j-log4j12-1.7.21.jar! /Org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Fant 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 av typen [org.slf4j.impl.Log4jLoggerFactory]

Denne advarselen forteller oss at SLF4J har funnet to bindinger. Man er inne slf4j-log4j12-1.7.21.jar og den andre i logback-classic-1.1.7.jar.

La oss forstå hvorfor vi ser denne advarselen.

Simple Logging Facade for Java (SLF4J) fungerer som en enkel fasade eller abstraksjon for ulike loggerammer. Dermed lar det oss koble til ønsket loggingsrammeverk ved distribusjonstidspunktet.

For å oppnå dette ser SLF4J etter bindinger (aka leverandører) på klassestien. Bindinger er i utgangspunktet implementeringer av en bestemt SLF4J-klasse ment å utvides til å plugge inn et bestemt loggingsrammeverk.

Etter design vil SLF4J bare binde med ett loggingsrammeverk om gangen. Følgelig hvis mer enn en binding er til stede på kursstien, vil den gi en advarsel.

Det er verdt å merke seg at innebygde komponenter som biblioteker eller rammer aldri skal erklære en avhengighet av noen SLF4J-binding. Dette er fordi når et bibliotek erklærer en avhengighet av kompileringstid på en SLF4J-binding, pålegger den den bindingen for sluttbrukeren. Åpenbart negerer dette SLF4Js grunnleggende formål. Derfor bør de bare avhenge av slf4j-api bibliotek.

Det er også viktig å merk at dette kun er en advarsel. Hvis SLF4J finner flere bindinger, velger den ett loggingsrammeverk fra listen og bindes med det. Som det kan sees på den siste linjen i advarselen, har SLF4J valgt Log4j ved å bruke org.slf4j.impl.Log4jLoggerFactory for selve bindingen.

3. Finne de motstridende JAR-ene

Advarselen viser stedene til alle bindingene den finner. Vanligvis er dette tilstrekkelig informasjon for å identifisere den skruppelløse avhengigheten som transitt trekker inn en uønsket SLF4J-binding i prosjektet vårt.

Hvis det ikke er mulig å identifisere avhengigheten fra advarselen, kan vi bruke avhengighet: tre maven mål:

mvn avhengighet: tre

Dette viser avhengighetstreet for prosjektet:

[INFO] + - org.docx4j: docx4j: jar: 3.3.5: kompilere [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 bruker Logback for å logge inn i applikasjonen vår. Derfor har vi lagt til Logback-bindingen, som er tilstede i logback-classic JAR, bevisst. Men docx4j avhengighet har også trukket inn en annen binding med slf4j-log4j12 KRUKKE.

4. Oppløsning

Nå som vi kjenner den fornærmende avhengigheten, er alt vi trenger å utelukke slf4j-log4j12 JAR fra docx4j avhengighet:

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

Siden vi ikke skal bruke Log4j, kan det være lurt å ekskludere det også.

5. Konklusjon

I denne artikkelen så vi hvordan vi kan løse advarselen om flere bindinger som sendes ut av SLF4J.

Kildekoden som følger med denne artikkelen, er tilgjengelig på GitHub.