streamalism.org

1. Oversikt

Simple Logging Facade for Java (forkortet SLF4J) - fungerer som en fasade for forskjellige loggerammer (f.eks. Java.util.logging, logback, Log4j). Den tilbyr en generell API som gjør loggingen uavhengig av den faktiske implementeringen.

Dette gjør at ulike loggerammer kan eksistere sammen. Det hjelper også med å migrere fra ett rammeverk til et annet. Til slutt, bortsett fra standardisert API, tilbyr den også noe “syntaktisk sukker”.

Denne artikkelen vil diskutere avhengigheter og konfigurasjon som trengs for å integrere SLF4J med Log4j2, Logback, Log4J2 og Jakarta Commons Logging. Mer om hver av disse implementeringene kan du lese i artikkelen Introduksjon til Java Logging.

2.Log4j2-oppsettet

For å bruke SLF4J med Log4j2, bør du legge til følgende biblioteker i pom.xml:

 org.apache.logging.log4j log4j-api 2.7 org.apache.logging.log4j log4j-core 2.7 org.apache.logging.log4j log4j-slf4j-impl 2.7 

Den siste versjonen finner du her: log4j-api, log4j-core, log4j-slf4j-impl.

Den faktiske loggkonfigurasjonen følger den opprinnelige Log4j 2-konfigurasjonen. La oss se hvordan Logger forekomst opprettes:

offentlig klasse SLF4JEeksempel {privat statisk loggerlogger = LoggerFactory.getLogger (SLF4JExample.class); public static void main (String [] args) {logger.debug ("Feilsøkingsloggmelding"); logger.info ("Informasjonsloggmelding"); logger.error ("Feilloggmelding"); }}

Merk at Logger og LoggerFactory tilhører org.slf4j pakke. Et eksempel på et prosjekt som kjører med den forklarte konfigurasjonen er tilgjengelig her.

3.Tilbakestillingsoppsettet

For å bruke SLF4J med Logback trenger du ikke å legge SLF4J til klassestien din. Logback bruker allerede SLF4J. Det regnes som referanseimplementering. Vi trenger bare å inkludere Logback-biblioteket:

 ch.qos.logback logback-classic 1.1.7 

Den siste versjonen finner du her: logback-classic.

Konfigurasjonen er Logback-spesifikk, men fungerer sømløst med SLF4J. Med riktig avhengighet og konfigurasjon på plass, kan den samme koden fra forrige seksjoner brukes til å håndtere loggingen.

4.Log4j-oppsettet

I de forrige avsnittene dekket vi en brukstilfelle der SLF4J "sitter" på toppen av den spesielle loggingen. Brukt på denne måten, trekker den fullstendig bort det underliggende rammeverket.

Det er tilfeller når en eksisterende loggløsning ikke kan erstattes, f.eks. på grunn av tredjeparts krav. Dette betyr imidlertid ikke at prosjektet bare blir "dømt" til det allerede brukte rammeverket.

SLF4J kan konfigureres som en bro, der samtalene til et eksisterende rammeverk blir omdirigert til det. La oss legge til de nødvendige avhengighetene for å lage en bro for Log4j:

 org.slf4j log4j-over-slf4j 1.7.30 

Med avhengigheten på plass (sjekk for siste på log4j-over-slf4j) vil alle samtalene til Log4j bli omdirigert til SLF4J. Vurder den offisielle dokumentasjonen for å lære mer om å bygge bro over eksisterende rammer.

Akkurat som med de andre rammene, kan Log4j tjene som en underliggende implementering. La oss legge til de nødvendige avhengighetene:

 org.slf4j slf4j-log4j12 1.7.30 log4j log4j 1.2.17 

Siste versjon finner du her for slf4j-log4j12 og log4j. Et eksemplarisk prosjekt, konfigurert på den forklarte måten, er tilgjengelig her.

5.JCL Bridge Setup

I de forrige avsnittene viste vi hvordan den samme kodebasen kan brukes til å støtte logging ved hjelp av forskjellige implementeringer. Selv om dette er hovedløftet og styrken til SLF4J, er det også målet bak JCL (Jakarta Commons Logging eller Apache Commons Logging).

JCL er etter sine intensjoner et rammeverk som ligner på SLF4J. Den største forskjellen er at JCL løser den underliggende implementeringen under utførelsestiden gjennom et klasselastningssystem. Denne tilnærmingen oppleves problematisk i tilfeller der det er tilpassede klasselastere på spill.

SLF4J løser bindingene sine ved kompileringstid. Det oppleves enklere, men likevel kraftig nok.

Heldigvis kan to rammer fungere sammen i bromodus:

 org.slf4j jcl-over-slf4j 1.7.30 

Den siste avhengighetsversjonen finner du her jcl-over-slf4j.

Som med de andre tilfellene, vil den samme kodebasen kjøre helt fint. Et eksempel på et komplett prosjekt som kjører dette oppsettet er tilgjengelig her.

6. Lengre SLF4J Godhet

SLF4J gir tillegg som kan gjøre loggingen mer effektiv og kode mer lesbar. For eksempel gir SLF4J et veldig nyttig grensesnitt for å jobbe med parametere:

Stringvariabel = "Hei John"; logger.debug ("Utskriftsvariabelverdi: {}", variabel);

Her er kodeeksemplet på Log4j som gjør det samme:

Stringvariabel = "Hei John"; logger.debug ("Utskriftsvariabelverdi:" + variabel);

Som du kan se, vil Log4j sammenføyes Strenger uansett feilsøke nivået er aktivert eller ikke. I applikasjoner med høy belastning kan dette føre til ytelsesproblemer. SLF4J vil sammenkobles Strenger bare når feilsøke er aktivert. For å gjøre det samme med Log4J må du legge til ekstra hvis blokk som vil sjekke om feilsøke nivå er aktivert eller ikke:

Stringvariabel = "Hei John"; hvis (logger.isDebugEnabled ()) {logger.debug ("Utskriftsvariabelverdi:" + variabel); }

SLF4J standardiserte loggnivåene som er forskjellige for de spesielle implementeringene. De FATAL loggningsnivået falt (det ble introdusert i Log4j) basert på forutsetningen om at vi i et loggingsrammeverk ikke skal bestemme når en applikasjon skal avsluttes.

Loggningsnivåene som brukes er FEIL, ADVARSEL, INFO, DEBUG, SPOR. Du kan lese mer om bruk av dem i artikkelen Introduksjon til Java-logging.

7. Konklusjon

SLF4J hjelper med lydløs veksling mellom loggerammer. Den er enkel, men likevel fleksibel, og gir mulighet for lesbarhet og ytelsesforbedringer.

Som vanlig kan du finne koden på GitHub. I tillegg refererer vi til to andre prosjekter dedikert til forskjellige artikler, men inneholder diskuterte loggkonfigurasjoner, her og her.