Java-logningsramme - Java logging framework

En Java-logningsramme er en pakke til datalogning af computere til Java-platformen . Denne artikel dækker rammer for logning af generelle formål.

Logning henviser til registrering af aktivitet af en applikation og er et almindeligt problem for udviklingsteams. Logningsrammer letter og standardiserer loggningsprocessen til Java-platformen. Især giver de fleksibilitet ved at undgå eksplicit output til konsollen (se Appender nedenfor). Hvor logfiler skrives, bliver uafhængig af koden og kan tilpasses ved kørsel.

Desværre inkluderede JDK ikke logning i sin oprindelige udgivelse, så da Java Logging API blev tilføjet, var flere andre logningsrammer blevet meget udbredt - især Apache Commons Logging (også kendt som Java Commons Logging eller JCL) og log4j . Dette førte til problemer ved integrering af forskellige tredjepartsbiblioteker (JAR), der hver bruger forskellige logningsrammer. Pluggbare logningsrammer (wrappers) blev udviklet for at løse dette problem.

Funktionsoversigt

Logning er typisk opdelt i tre hovedstykker: Logger, Formatter og Appender (eller Handler).

  • Loggeren er ansvarlig for at opfange den besked, der skal logges sammen med bestemte metadata og videresende den til logningsrammen.
  • Efter modtagelse af meddelelsen kalder rammen op til Formatter med meddelelsen, som formaterer den til output.
  • Rammen afleverer derefter den formaterede besked til den relevante Appender / Handler til disposition. Dette kan omfatte output til en konsolskærm, skrivning til disk, tilføjelse til en database eller generering af en e-mail.

Enklere logningsrammer, som Logging Framework af Object Guy , kombinerer loggeren og appenderen. Dette forenkler standardhandling, men det er mindre konfigurerbart, især hvis projektet flyttes på tværs af miljøer.

Logger

En logger er et objekt, der giver applikationen mulighed for at logge uden hensyn til, hvor output sendes / lagres. Applikationen logger en meddelelse ved at sende et objekt eller et objekt og en undtagelse med et valgfrit sværhedsgrad til loggerobjektet under et givet navn / identifikator.

Navn

En logger har et navn. Navnet er normalt struktureret hierarkisk, hvor perioder (.) Adskiller niveauerne. En almindelig ordning er at bruge navnet på den klasse eller pakke, der logger. Både log4j og Java logging API understøtter definition af håndterere højere op i hierarkiet.

For eksempel kan loggeren have navnet " com.sun.some.UsefulClass ". Handleren kan defineres for et af følgende:

  • com
  • com.sun
  • com.sun.some
  • com.sun.some.UsefulClass

Så længe der er defineret en handler et eller andet sted i denne stak, kan der forekomme logning. For eksempel kan en besked, der er logget på com.sun.some.UsefulClass loggeren, blive skrevet af com.sun handleren. Der er typisk en global handler, der modtager og behandler meddelelser genereret af enhver logger.

Alvorlighedsniveau

Meddelelsen logges på et bestemt niveau. Almindelige niveau navne kopieres fra Apache Commons Logging (selvom Java Logging API definerer forskellige niveau navne):

Fælles niveauer
Niveau Beskrivelse
FATAL Alvorlige fejl, der forårsager for tidlig opsigelse. Forvent at disse straks er synlige på en statuskonsol.
FEJL Andre runtime-fejl eller uventede forhold. Forvent at disse straks er synlige på en statuskonsol.
ADVARSEL Brug af forældede API'er, dårlig brug af API, 'næsten' fejl, andre runtime-situationer, der er uønskede eller uventede, men ikke nødvendigvis "forkerte". Forvent at disse straks er synlige på en statuskonsol.
INFO Interessante runtime-begivenheder (opstart / nedlukning). Forvent at disse er umiddelbart synlige på en konsol, så vær konservativ og hold et minimum.
FEJLFINDE detaljerede oplysninger om strømmen gennem systemet. Forvent, at disse kun skrives til logfiler.
SPOR mere detaljerede oplysninger. Forvent, at disse kun skrives til logfiler.

Logningsrammen opretholder det aktuelle logningsniveau for hver logger. Logningsniveauet kan indstilles mere eller mindre restriktivt. For eksempel, hvis logningsniveauet er indstillet til "ADVARSEL", logges alle meddelelser på dette niveau eller højere: FEJL og FATAL.

Alvorlighedsniveauer kan tildeles både loggere og appenders. Begge skal være aktiveret for et givet alvorlighedsniveau for at output kan genereres. Så en logger, der er aktiveret til debug-output, genererer ikke output, hvis den behandler, der får beskeden, ikke også er aktiveret til debug.

Filtre

Filtre får en loghændelse til at blive ignoreret eller logget. Det mest anvendte filter er logningsniveauet, der er dokumenteret i det foregående afsnit. Logningsrammer som Log4j 2 og SLF4J giver også markører, som, når de er knyttet til en loghændelse, også kan bruges til filtrering. Filtre kan også bruges til at acceptere eller afvise loghændelser baseret på undtagelser, der kastes, data i logmeddelelsen, data i en ThreadLocal, der er eksponeret gennem loggings-API'en, eller en række andre metoder.

Formaterere, layout eller gengivere

En formatering er et objekt, der formaterer et givet objekt. Dette består hovedsageligt af at tage det binære objekt og konvertere det til en strengrepræsentation. Hver ramme definerer et standardoutputformat, der kan tilsidesættes, hvis det ønskes.

Appenders eller handlers

Appenders lytter efter meddelelser på eller over et specificeret minimumsgradeniveau. Appenderen tager den besked, den sendes, og sender den korrekt. Besked dispositioner inkluderer:

  • vises på konsollen
  • skriv til en fil eller syslog
  • føje til en databasetabel
  • distribuere via Java Messaging Services
  • send via e-mail
  • skriv til en stikkontakt
  • kassér til "bit-bucket" (/ dev / null)

Funktionssammenligning

Tabel 1 - Funktioner
Ramme Type Understøttede logniveauer Standard appenders Kommentarer Omkostninger / licens
Log4J Logning Framework FATAL ERROR WARN INFO DEBUG TRACE For mange til at liste: Se Appenderdokumentation Udbredt i mange projekter og platforme. Log4j 1 blev erklæret "End of Life" i 2015 og er blevet erstattet med Log4j 2, som giver en API, der kan bruges sammen med andre loggeimplementeringer såvel som en implementering af denne API.
Apache-licens, version 2.0
Java Logging API Logning Framework SEVERE WARNING INFO CONFIG FINE FINER FINEST Suns standard Java Virtual Machine (JVM) har følgende: ConsoleHandler, FileHandler, SocketHandler, MemoryHandler Leveres med JRE
tinylog Logning Framework ERROR WARNING INFO DEBUG TRACE ConsoleWriter, FileWriter, LogcatWriter, JdbcWriter, RollingFileWriter, SharedFileWriter og null (kasserer alle logposter) Apache-licens, version 2.0
Logback Logning Framework ERROR WARN INFO DEBUG TRACE For mange til at liste: se Appender JavaDoc Udviklet som erstatning for log4j med mange forbedringer. Brugt af mange projekter, typisk bag slf4j, for eksempel Akka , Apache Camel , Apache Cocoon , Artifactory , Gradle , Lift Framework , Play Framework , Scalatra , SonarQube , Spring Boot , ... LGPL , version 2.1
Apache Commons Logging (JCL) Logging indpakning FATAL ERROR WARN INFO DEBUG TRACE Afhænger af den underliggende ramme Udbredt, ofte i forbindelse med log4j Apache-licens, version 2.0
SLF4J Logging indpakning ERROR WARN INFO DEBUG TRACE Afhænger af den underliggende ramme, som er tilslutbar. Tilbyder API-kompatible shims til JCL-, JDK- og log4j-logningspakker. Det kan også bruge nogen af ​​dem til at generere output. Som standard bruges Logback til output, hvis det er tilgængeligt. Udbredt i mange projekter og platforme, ofte med Logback som implementering. MIT-licens

Overvejelser

JCL og Log4j er meget almindelige simpelthen fordi de har eksisteret så længe og var de eneste valg i lang tid. Fleksibiliteten ved slf4j (ved hjælp af Logback nedenunder) har gjort det til et populært valg.

SLF4J er et sæt loggeindpakninger (eller shims), der gør det muligt at efterligne et af de andre rammer. Således kan flere tredjepartsbiblioteker inkorporeres i en applikation, uanset hvilken logningsramme hver har valgt at bruge. Al logningoutput genereres dog på en standard måde, typisk via Logback.

Log4j 2 giver både en API og en implementering. API'et kan dirigeres til andre logningsimplementeringer svarende til, hvordan SLF4J fungerer. I modsætning til SLF4J logger Log4j 2 API meddelelsesobjekter i stedet for strenge for ekstra fleksibilitet og understøtter også Java Lambda-udtryk.

JCL er ikke rigtig en logningsramme, men en indpakning til en. Som sådan kræver det en logningsramme under den, selvom den som standard kan bruge sin egen SimpleLog logger.

JCL, SLF4J og Log4j 2 API er nyttige, når der udvikles genbrugsbiblioteker, der skal skrive til det underliggende logningssystem, der bruges af applikationen. Dette giver også fleksibilitet i heterogene miljøer, hvor logningsrammen sandsynligvis vil ændre sig, selvom der i de fleste tilfælde, når der er valgt en logningsramme, er der ringe behov for at ændre den i løbet af projektets levetid. SLF4J og Log4j 2 drager fordel af at være nyere og bygge videre på erfaringerne fra ældre rammer. Desuden har JCL kendt problemer med klasselæssere, når de bestemmer, hvilket loggningsbibliotek det skal pakke, som nu har erstattet JCL.

Java Logging API leveres med Java. Selvom API'en er teknisk adskilt fra standardimplementeringen leveret med Java, kan det være en udfordring at erstatte den med en alternativ implementering, så mange udviklere forveksler denne implementering med Java Logging API. Konfiguration sker kun ved hjælp af eksterne filer, som ikke let kan ændres i farten (andre rammer understøtter programmatisk konfiguration). Standardimplementeringen giver kun et par håndterere og formater, hvilket betyder, at de fleste brugere bliver nødt til at skrive deres egne.

Se også

Referencer

eksterne links