streamalism.org

1. Oversigt

Simple Logging Facade for Java (forkortet SLF4J) - fungerer som en facade til forskellige logningsrammer (f.eks. Java.util.logging, logback, Log4j). Det tilbyder en generisk API, der gør logning uafhængig af den faktiske implementering.

Dette giver mulighed for, at forskellige logningsrammer kan eksistere sammen. Det hjælper også med at migrere fra en ramme til en anden. Endelig tilbyder den bortset fra standardiseret API også noget “syntaktisk sukker”.

Denne artikel vil diskutere de afhængigheder og konfiguration, der er nødvendige for at integrere SLF4J med Log4j2, Logback, Log4J2 og Jakarta Commons Logging. Mere om hver af disse implementeringer kan du læse i artiklen Introduktion til Java-logning.

2.Log4j2-opsætningen

For at bruge SLF4J med Log4j2 skal du tilføje følgende biblioteker til 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 seneste version kan findes her: log4j-api, log4j-core, log4j-slf4j-impl.

Den faktiske logningskonfiguration overholder den oprindelige Log4j 2-konfiguration. Lad os se, hvordan Logger forekomst oprettes:

offentlig klasse SLF4JEeksempel {privat statisk loggerlogger = LoggerFactory.getLogger (SLF4JExample.class); public static void main (String [] args) {logger.debug ("Fejlfindingslogmeddelelse"); logger.info ("Info logmeddelelse"); logger.error ("Fejllogmeddelelse"); }}

Bemærk, at Logger og LoggerFabrik hører til org.slf4j pakke. Et eksempel på et projekt, der kører med den forklarede konfiguration, er tilgængelig her.

3.Logback-opsætningen

For at bruge SLF4J med Logback behøver du ikke tilføje SLF4J til din klassesti. Logback bruger allerede SLF4J. Det betragtes som referenceimplementeringen. Vi behøver kun at inkludere Logback-biblioteket:

 ch.qos.logback logback-classic 1.1.7 

Den seneste version kan findes her: logback-classic.

Konfigurationen er Logback-specifik, men fungerer problemfrit med SLF4J. Med de rette afhængigheder og konfiguration på plads kan den samme kode fra tidligere sektioner bruges til at håndtere logning.

4.Log4j-opsætningen

I de foregående afsnit dækkede vi en use-case, hvor SLF4J “sidder” oven på den særlige logningimplementering. Brugt på denne måde abstraherer den den underliggende ramme fuldstændigt.

Der er tilfælde, hvor en eksisterende logningsløsning ikke kan erstattes, f.eks. på grund af tredjeparts krav. Dette betyder dog ikke, at projektet kun "dømmes" til den allerede anvendte ramme.

SLF4J kan konfigureres som en bro, hvor opkaldene til en eksisterende ramme omdirigeres til den. Lad os tilføje de nødvendige afhængigheder for at oprette en bro til Log4j:

 org.slf4j log4j-over-slf4j 1.7.30 

Med afhængigheden på plads (tjek senest på log4j-over-slf4j), omdirigeres alle opkald til Log4j til SLF4J. Overvej den officielle dokumentation for at lære mere om at bygge bro over eksisterende rammer.

Ligesom med de andre rammer kan Log4j tjene som en underliggende implementering. Lad os tilføje de nødvendige afhængigheder:

 org.slf4j slf4j-log4j12 1.7.30 log4j log4j 1.2.17 

Seneste version kan findes her til slf4j-log4j12 og log4j. Et eksempel på et projekt, der er konfigureret på den forklarede måde, er tilgængeligt her.

5.JCL Bridge-opsætning

I de foregående afsnit viste vi, hvordan den samme kodebase kan bruges til at understøtte logning ved hjælp af forskellige implementeringer. Selvom dette er SLF4Js største løfte og styrke, er det også målet bag JCL (Jakarta Commons Logging eller Apache Commons Logging).

JCL er efter sine intentioner en ramme svarende til SLF4J. Den største forskel er, at JCL løser den underliggende implementering under udførelsestid gennem et klassesystem. Denne tilgang opfattes som problematisk i tilfælde, hvor der er brugerdefinerede klasselæsere i spil.

SLF4J løser sine bindinger på kompileringstidspunktet. Det opfattes enklere, men alligevel kraftigt nok.

Heldigvis kan to rammer arbejde sammen i brotilstand:

 org.slf4j jcl-over-slf4j 1.7.30 

Den seneste afhængighedsversion kan findes her jcl-over-slf4j.

Som med de andre tilfælde kører den samme kodebase fint. Et eksempel på et komplet projekt, der kører denne opsætning, er tilgængelig her.

6. Yderligere SLF4J Godhed

SLF4J giver ekstra, der kan gøre logning mere effektiv og kode mere læselig. F.eks. Giver SLF4J en meget nyttig grænseflade til at arbejde med parametre:

Strengvariabel = "Hej John"; logger.debug ("Udskrivning af variabelværdi: {}", variabel);

Her er kodeeksemplet på Log4j, der gør det samme:

Strengvariabel = "Hej John"; logger.debug ("Udskrivning af variabelværdi:" + variabel);

Som du kan se, sammenkobles Log4j Strenge uanset fejlfinde niveau aktiveret eller ej. I applikationer med høj belastning kan dette medføre ydeevneproblemer. SLF4J sammenkædes Strenge kun når fejlfinde niveau er aktiveret. For at gøre det samme med Log4J skal du tilføje ekstra hvis blok, som vil kontrollere, om fejlfinde niveau er aktiveret eller ej:

Strengvariabel = "Hej John"; hvis (logger.isDebugEnabled ()) {logger.debug ("Udskrivning af variabelværdi:" + variabel); }

SLF4J standardiserede logningsniveauerne, der er forskellige for de specifikke implementeringer. Det FATAL logningsniveau blev droppet (det blev introduceret i Log4j) baseret på den forudsætning, at vi i en logningsramme ikke skulle beslutte, hvornår en ansøgning skulle afsluttes.

De anvendte logningsniveauer er FEJL, ADVARSEL, INFO, DEBUG, SPOR. Du kan læse mere om brugen af ​​dem i artiklen Introduktion til Java-logning.

7. Konklusion

SLF4J hjælper med lydløs skift mellem logningsrammer. Det er simpelt, men alligevel fleksibelt og giver mulighed for læsbarhed og ydeevne forbedringer.

Som sædvanlig kan koden findes på GitHub. Derudover henviser vi til to andre projekter dedikeret til forskellige artikler, men indeholder diskuterede logkonfigurationer her og her.