Einführung in SLF4J

1. Übersicht

Einfache Protokollierungsfassade für Java (abgekürzt SLF4J) - fungiert als Fassade für verschiedene Protokollierungsframeworks (z. B. java.util.logging, logback, Log4j). Es bietet eine generische API, die die Protokollierung unabhängig von der tatsächlichen Implementierung macht.

Dadurch können verschiedene Protokollierungsframeworks nebeneinander existieren. Es hilft auch bei der Migration von einem Framework zu einem anderen. Schließlich bietet es neben der standardisierten API auch etwas „syntaktischen Zucker“.

In diesem Artikel werden die Abhängigkeiten und Konfigurationen erläutert, die für die Integration von SLF4J in Log4j2, Logback, Log4J2 und Jakarta Commons Logging erforderlich sind. Weitere Informationen zu jeder dieser Implementierungen finden Sie im Artikel Einführung in die Java-Protokollierung.

2. Das Log4j2-Setup

Um SLF4J mit Log4j2 zu verwenden, sollten Sie pom.xml die folgenden Bibliotheken hinzufügen :

 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 

Die neueste Version finden Sie hier: log4j-api, log4j-core, log4j-slf4j-impl.

Die eigentliche Protokollierungskonfiguration entspricht der nativen Log4j 2-Konfiguration. Mal sehen, wie die Logger- Instanz erstellt wird:

public class SLF4JExample { private static Logger logger = LoggerFactory.getLogger(SLF4JExample.class); public static void main(String[] args) { logger.debug("Debug log message"); logger.info("Info log message"); logger.error("Error log message"); } }

Beachten Sie, dass der Logger und LoggerFactory gehören zum org.slf4j Paket. Ein Beispiel für ein Projekt, das mit der erläuterten Konfiguration ausgeführt wird, finden Sie hier.

3. Das Logback-Setup

Um SLF4J mit Logback zu verwenden, müssen Sie Ihrem Klassenpfad kein SLF4J hinzufügen. Logback verwendet bereits SLF4J. Es wird als Referenzimplementierung betrachtet. Wir müssen nur die Logback-Bibliothek einschließen:

 ch.qos.logback logback-classic 1.1.7 

Die neueste Version finden Sie hier: logback-classic.

Die Konfiguration ist Logback-spezifisch, funktioniert jedoch nahtlos mit SLF4J. Mit den richtigen Abhängigkeiten und Konfigurationen kann derselbe Code aus den vorherigen Abschnitten für die Protokollierung verwendet werden.

4 . Das Log4j-Setup

In den vorherigen Abschnitten haben wir einen Anwendungsfall behandelt, bei dem SLF4J über der jeweiligen Protokollierungsimplementierung „sitzt“. Bei dieser Verwendung wird das zugrunde liegende Framework vollständig abstrahiert.

Es gibt Fälle, in denen eine vorhandene Protokollierungslösung nicht ersetzt werden kann, z. B. aufgrund von Anforderungen Dritter. Dies bedeutet jedoch nicht, dass das Projekt nur zu dem bereits verwendeten Rahmen „verurteilt“ wird.

SLF4J kann als Bridge konfiguriert werden, bei der die Aufrufe eines vorhandenen Frameworks an dieses umgeleitet werden. Fügen wir die erforderlichen Abhängigkeiten hinzu, um eine Brücke für Log4j zu erstellen:

 org.slf4j log4j-over-slf4j 1.7.30 

Wenn die Abhängigkeit besteht (prüfen Sie, ob sie unter log4j-over-slf4j auf dem neuesten Stand ist), werden alle Aufrufe von Log4j an SLF4J umgeleitet. Lesen Sie die offizielle Dokumentation, um mehr über die Überbrückung bestehender Frameworks zu erfahren.

Genau wie bei den anderen Frameworks kann Log4j als zugrunde liegende Implementierung dienen. Fügen wir die erforderlichen Abhängigkeiten hinzu:

 org.slf4j slf4j-log4j12 1.7.30   log4j log4j 1.2.17 

Die neueste Version für slf4j-log4j12 und log4j finden Sie hier. Ein beispielhaftes Projekt, das auf die erläuterte Weise konfiguriert wurde, finden Sie hier.

5. JCL Bridge Setup

In den vorherigen Abschnitten haben wir gezeigt, wie dieselbe Codebasis zur Unterstützung der Protokollierung mit verschiedenen Implementierungen verwendet werden kann. Dies ist zwar das Hauptversprechen und die Stärke von SLF4J, aber auch das Ziel von JCL (Jakarta Commons Logging oder Apache Commons Logging).

JCL ist aufgrund seiner Absichten ein Framework, das SLF4J ähnelt. Der Hauptunterschied besteht darin, dass JCL die zugrunde liegende Implementierung während der Ausführungszeit über ein Klassenladesystem auflöst. Dieser Ansatz wird in Fällen als problematisch empfunden, in denen benutzerdefinierte Klassenlader im Spiel sind.

SLF4J löst seine Bindungen zur Kompilierungszeit auf. Es wird einfacher und doch mächtig genug wahrgenommen.

Glücklicherweise können im Bridge-Modus zwei Frameworks zusammenarbeiten:

 org.slf4j jcl-over-slf4j 1.7.30 

Die neueste Abhängigkeitsversion finden Sie hier jcl-over-slf4j.

Wie in den anderen Fällen läuft dieselbe Codebasis einwandfrei. Ein Beispiel für ein vollständiges Projekt, in dem dieses Setup ausgeführt wird, finden Sie hier.

6. Weitere SLF4J Güte

SLF4J bietet zusätzliche Funktionen, mit denen die Protokollierung effizienter und der Code lesbarer wird. Zum Beispiel bietet SLF4J eine sehr nützliche Schnittstelle für die Arbeit mit Parametern:

String variable = "Hello John"; logger.debug("Printing variable value: {}", variable);

Hier ist das Codebeispiel von Log4j, das dasselbe tut:

String variable = "Hello John"; logger.debug("Printing variable value: " + variable);

Wie Sie sehen können, verkettet Log4j Strings unabhängig davon , ob die Debug- Ebene aktiviert ist oder nicht. In Hochlastanwendungen kann dies zu Leistungsproblemen führen. SLF4J verkettet Strings nur, wenn die Debug- Ebene aktiviert ist. Um dasselbe mit Log4J zu tun, müssen Sie einen zusätzlichen if- Block hinzufügen , der prüft, ob die Debugstufe aktiviert ist oder nicht:

String variable = "Hello John"; if (logger.isDebugEnabled()) { logger.debug("Printing variable value: " + variable); }

SLF4J standardisierte die Protokollierungsstufen, die für die jeweiligen Implementierungen unterschiedlich sind. Die FATAL- Protokollierungsstufe wurde gelöscht (sie wurde in Log4j eingeführt), basierend auf der Annahme, dass wir in einem Protokollierungsframework nicht entscheiden sollten, wann eine Anwendung beendet werden soll.

Die verwendeten Protokollierungsstufen sind ERROR, WARN, INFO, DEBUG, TRACE . Weitere Informationen zu deren Verwendung finden Sie im Artikel Einführung in die Java-Protokollierung.

7. Fazit

SLF4J hilft beim leisen Umschalten zwischen Protokollierungsframeworks. Es ist einfach und dennoch flexibel und ermöglicht Lesbarkeits- und Leistungsverbesserungen.

Wie üblich ist der Code auf GitHub zu finden. Darüber hinaus verweisen wir auf zwei andere Projekte, die verschiedenen Artikeln gewidmet sind, aber hier und hier besprochene Protokollkonfigurationen enthalten.