Java-framework voor logboekregistratie - Java logging framework
Een Java-logboekregistratieframework is een logboekpakket voor computergegevens voor het Java-platform . Dit artikel behandelt algemene kaders voor logboekregistratie.
Logboekregistratie verwijst naar het registreren van activiteit door een applicatie en is een veelvoorkomend probleem voor ontwikkelingsteams. Logging-frameworks vereenvoudigen en standaardiseren het logboekregistratieproces voor het Java-platform. Ze bieden in het bijzonder flexibiliteit door expliciete uitvoer naar de console te vermijden (zie Appender hieronder). Waar logboeken worden geschreven, wordt onafhankelijk van de code en kan tijdens runtime worden aangepast.
Helaas bevatte de JDK logging niet in de oorspronkelijke release, dus tegen de tijd dat de Java Logging API werd toegevoegd, waren er verschillende andere logging-frameworks op grote schaal gebruikt - in het bijzonder Apache Commons Logging (ook bekend als Java Commons Logging of JCL) en log4j . Dit leidde tot problemen bij het integreren van verschillende bibliotheken van derden (JAR's) die elk verschillende logging-frameworks gebruikten. Om dit probleem op te lossen zijn pluggable logging frameworks (wrappers) ontwikkeld.
Functionaliteitsoverzicht
Logboekregistratie wordt doorgaans opgesplitst in drie grote delen: de logger, de formatter en de appender (of handler).
- De logger is verantwoordelijk voor het vastleggen van het te loggen bericht samen met bepaalde metadata en het doorgeven aan het logging framework.
- Na ontvangst van het bericht roept het framework de Formatter aan met het bericht dat het opmaakt voor uitvoer.
- Het raamwerk geeft het opgemaakte bericht vervolgens ter beschikking aan de juiste Appender / Handler. Dit kan uitvoer zijn naar een consolescherm, schrijven naar schijf, toevoegen aan een database of het genereren van een e-mailbericht.
Eenvoudigere logging-frameworks, zoals Logging Framework van de Object Guy , combineren de logger en de appender. Dit vereenvoudigt de standaardwerking, maar is minder configureerbaar, vooral als het project naar verschillende omgevingen wordt verplaatst.
Logger
Een logger is een object waarmee de toepassing kan loggen, ongeacht waar de uitvoer wordt verzonden / opgeslagen. De toepassing registreert een bericht door een object of een object en een uitzondering met een optioneel prioriteitsniveau door te geven aan het loggerobject onder een bepaalde naam / identificatie.
Naam
Een logger heeft een naam. De naam is meestal hiërarchisch gestructureerd, met punten (.) Die de niveaus scheiden. Een veelvoorkomend schema is om de naam te gebruiken van de klasse of het pakket dat de logboekregistratie uitvoert. Zowel log4j als de Java-logging- API ondersteunen het definiëren van handlers hoger in de hiërarchie.
De logger kan bijvoorbeeld " com.sun.some.UsefulClass " heten . De handler kan worden gedefinieerd voor een van de volgende:
comcom.suncom.sun.somecom.sun.some.UsefulClass
Zolang er ergens in deze stapel een handler is gedefinieerd, kan logboekregistratie plaatsvinden. Een bericht dat bijvoorbeeld bij de com.sun.some.UsefulClass logger is geregistreerd , kan door de com.sun handler worden geschreven . Meestal is er een globale handler die berichten ontvangt en verwerkt die door een logger worden gegenereerd.
Ernstniveau
Het bericht wordt op een bepaald niveau gelogd. Algemene niveaunamen worden gekopieerd van Apache Commons Logging (hoewel de Java Logging API verschillende niveaunamen definieert):
| Niveau | Omschrijving |
|---|---|
| FATAAL | Ernstige fouten die voortijdige beëindiging veroorzaken. Verwacht dat deze onmiddellijk zichtbaar zijn op een statusconsole. |
| FOUT | Andere runtimefouten of onverwachte omstandigheden. Verwacht dat deze onmiddellijk zichtbaar zijn op een statusconsole. |
| WAARSCHUWING | Gebruik van verouderde API's, slecht gebruik van API, 'bijna'-fouten, andere runtime-situaties die ongewenst of onverwacht zijn, maar niet noodzakelijk "fout". Verwacht dat deze onmiddellijk zichtbaar zijn op een statusconsole. |
| INFO | Interessante runtime-evenementen (opstarten / afsluiten). Verwacht dat deze onmiddellijk zichtbaar zijn op een console, dus wees conservatief en beperk ze tot een minimum. |
| DEBUG | gedetailleerde informatie over de stroom door het systeem. Verwacht dat deze alleen naar logboeken worden geschreven. |
| SPOOR | meer gedetailleerde informatie. Verwacht dat deze alleen naar logboeken worden geschreven. |
Het logging framework handhaaft het huidige logging niveau voor elke logger. Het registratieniveau kan meer of minder beperkend worden ingesteld. Als het logboekniveau bijvoorbeeld is ingesteld op "WAARSCHUWING", worden alle berichten van dat niveau of hoger gelogd: FOUT en FATAL.
Ernstniveaus kunnen worden toegewezen aan zowel loggers als appenders. Beide moeten zijn ingeschakeld voor een bepaald prioriteitsniveau om uitvoer te kunnen genereren. Dus een logger die is ingeschakeld voor foutopsporingsuitvoer zal geen uitvoer genereren als de handler die het bericht ontvangt, niet ook is ingeschakeld voor foutopsporing.
Filters
Filters zorgen ervoor dat een logboekgebeurtenis wordt genegeerd of gelogd. Het meest gebruikte filter is het registratieniveau dat in de vorige sectie is beschreven. Logging-frameworks zoals Log4j 2 en SLF4J bieden ook Markers, die, wanneer ze aan een loggebeurtenis zijn gekoppeld, ook kunnen worden gebruikt voor filtering. Filters kunnen ook worden gebruikt om logboekgebeurtenissen te accepteren of te weigeren op basis van uitzonderingen die worden gegenereerd, gegevens in het logboekbericht, gegevens in een ThreadLocal die wordt weergegeven via de logging-API of een verscheidenheid aan andere methoden.
Formatters, lay-outs of renderers
Een formatter is een object dat een bepaald object opmaakt. Meestal bestaat dit uit het nemen van het binaire object en het converteren naar een stringvoorstelling. Elk framework definieert een standaard uitvoerformaat dat indien gewenst kan worden overschreven.
Appenders of handlers
Appenders luisteren naar berichten op of boven een gespecificeerd minimum ernstniveau. De Appender neemt het bericht dat het is doorgegeven en plaatst het op de juiste manier. Berichtbeschrijvingen omvatten:
- display op de console
- schrijf naar een bestand of syslog
- toevoegen aan een databasetabel
- distribueren via Java Messaging Services
- verzenden via e-mail
- schrijf naar een stopcontact
- weggooien naar de "bit-bucket" (/ dev / null)
Feature vergelijking
| Kader | Type | Ondersteunde logniveaus | Standaard Appenders | Opmerkingen | Kosten / licentie |
|---|---|---|---|---|---|
| Log4J | Logging Framework |
FATAL ERROR WARN INFO DEBUG TRACE
|
Te veel om op te noemen: zie Appender-documentatie | Veel gebruikt in veel projecten en platforms. Log4j 1 werd in 2015 uitgeroepen tot "End of Life" en is vervangen door Log4j 2, dat een API biedt die kan worden gebruikt met andere logging-implementaties, evenals een implementatie van die API. |
Apache-licentie, versie 2.0
|
| Java-logboekregistratie-API | Logging Framework |
SEVERE WARNING INFO CONFIG FINE FINER FINEST
|
Sun's standaard Java Virtual Machine (JVM) heeft het volgende: ConsoleHandler, FileHandler, SocketHandler, MemoryHandler | Wordt geleverd met de JRE | |
| tinylog | Logging Framework |
ERROR WARNING INFO DEBUG TRACE
|
ConsoleWriter, FileWriter, LogcatWriter, JdbcWriter, RollingFileWriter, SharedFileWriter en null (verwijdert alle logboekvermeldingen) | Apache-licentie, versie 2.0 | |
| Log terug | Logging Framework |
ERROR WARN INFO DEBUG TRACE
|
Te veel om op te noemen: zie Appender JavaDoc | Ontwikkeld als vervanging voor log4j, met veel verbeteringen. Gebruikt door tal van projecten, typisch achter slf4j, bijvoorbeeld Akka , Apache Camel , Apache Cocoon , Artifactory , Gradle , Lift Framework , Play Framework , Scalatra , SonarQube , Spring Boot , ... | LGPL , versie 2.1 |
| Apache Commons-logboekregistratie (JCL) | Logboekregistratie wrapper |
FATAL ERROR WARN INFO DEBUG TRACE
|
Hangt af van het onderliggende raamwerk | Veel gebruikt, vaak in combinatie met log4j | Apache-licentie, versie 2.0 |
| SLF4J | Logboekregistratie wrapper |
ERROR WARN INFO DEBUG TRACE
|
Hangt af van het onderliggende raamwerk, dat insteekbaar is. Biedt API-compatibele shims voor JCL-, JDK- en log4j-logboekpakketten. Het kan ze ook allemaal gebruiken om output te genereren. Standaard wordt Logback gebruikt voor uitvoer, indien beschikbaar. | Op grote schaal gebruikt in veel projecten en platforms, vaak met Logback als implementatie. | MIT-licentie |
Overwegingen
JCL en Log4j komen heel vaak voor, simpelweg omdat ze al zo lang bestaan en lange tijd de enige keuzes waren. De flexibiliteit van slf4j (met behulp van Logback hieronder) heeft het tot een populaire keuze gemaakt.
SLF4J is een set logging wrappers (of shims) waarmee het elk van de andere frameworks kan imiteren. Zo kunnen meerdere bibliotheken van derden in een applicatie worden opgenomen, ongeacht het logging-framework dat elk heeft gekozen om te gebruiken. Alle logboekuitvoer wordt echter op een standaardmanier gegenereerd, meestal via Logback.
Log4j 2 biedt zowel een API als een implementatie. De API kan worden gerouteerd naar andere logging-implementaties die gelijk zijn aan hoe SLF4J werkt. In tegenstelling tot SLF4J registreert de Log4j 2 API Message-objecten in plaats van Strings voor extra flexibiliteit en ondersteunt het ook Java Lambda-expressies.
JCL is niet echt een logging-framework, maar een wrapper voor één. Als zodanig heeft het een logging-framework eronder nodig, hoewel het standaard zijn eigen SimpleLog logger kan gebruiken.
JCL, SLF4J en de Log4j 2 API zijn handig bij het ontwikkelen van herbruikbare bibliotheken die moeten schrijven naar het onderliggende logboeksysteem dat door de toepassing wordt gebruikt. Dit biedt ook flexibiliteit in heterogene omgevingen waar het logging-framework waarschijnlijk zal veranderen, hoewel het in de meeste gevallen, als eenmaal een logging-framework is gekozen, er weinig behoefte aan is om dit gedurende de levensduur van het project te veranderen. SLF4J en Log4j 2 profiteren van het feit dat ze nieuwer zijn en voortbouwen op de lessen die zijn geleerd uit oudere frameworks. Bovendien heeft JCL problemen met class-loaders gekend bij het bepalen welke logboekbibliotheek het moet omwikkelen, die nu JCL heeft vervangen.
De Java Logging API wordt geleverd bij Java. Hoewel de API technisch gescheiden is van de standaardimplementatie die bij Java wordt geleverd, kan het een uitdaging zijn om deze te vervangen door een alternatieve implementatie, dus veel ontwikkelaars verwarren deze implementatie met de Java Logging API. De configuratie gebeurt alleen door externe bestanden, die niet gemakkelijk direct kunnen worden gewijzigd (andere frameworks ondersteunen programmatische configuratie). De standaardimplementatie biedt slechts een paar handlers en formatters, wat betekent dat de meeste gebruikers hun eigen handlers zullen moeten schrijven.
Zie ook
- SLF4J
- log4j
- inloggen
- Javolution LogContext gebaseerd op context programmering (werkelijke logging kader selecteerbare op run-time).
- Runtime-intelligentie
Referenties
Externe links
- API voor logboekregistratie van Java 6.0
- Commons Logging
- Protomatter
- Open Source Logging Tools in Java
- De Apache 2.0-licentie.
- Logback - Een opvolger van het populaire log4j-project
- tinylog - Minimalistisch logboekprogramma met een statische logger
- Loggifier Een tool die inlogcode invoegt in .class-, .jar- en .ear-bestanden
- JLV - Java-logboekviewer die momenteel beschikbaar is als plug-in voor Eclipse IDE
- Perf4j
- SLF4J
- Log4j 2