it-swarm.com.de

Lohnt es sich, slf4j mit log4j2 zu verwenden?

Ich kann mich nicht entscheiden, ob ich slf4j mit log4j2 verwende oder nicht. Basierend auf Online-Posts sieht es nicht so aus, als hätte es Leistungseinbußen, aber es ist wirklich erforderlich.

Auch diese Punkte sprechen für log4j2:

  • SLF4J erzwingt, dass Ihre Anwendung Zeichenfolgen protokolliert. Die Log4j 2-API unterstützt die Protokollierung von CharSequence, wenn Sie Text protokollieren möchten, unterstützt jedoch auch die Protokollierung aller Objekte im aktuellen Zustand.
  • Die Log4j 2-API bietet Unterstützung für die Protokollierung von Message-Objekten, Java 8 Lambda-Ausdrücken und die müllfreie Protokollierung (es werden keine Vararg-Arrays und keine Strings beim Protokollieren von CharSequence-Objekten erstellt).
91
Andy897

Gehen Sie weiter: Programmieren Sie auf die log4j2-API anstelle von slf4j

Es ist sicher: Die Log4j2-API bietet genau die gleichen Garantien wie slf4j - und mehr.

Da Log4j2 selbst in eine API und ein Implementierungsmodul unterteilt ist, ist die Verwendung von SLF4J nicht mehr sinnvoll.

Ja, es ist eine gute technische Praxis, Ihre Optionen offen zu halten. Möglicherweise möchten Sie später zu einer anderen Protokollierungsimplementierung wechseln.

In den letzten 10 Jahren bedeutete der Aufbau einer solchen Flexibilität in Ihrer Anwendung die Verwendung einer Wrapper-API wie SLF4J. Diese Flexibilität ist jedoch nicht kostenlos: Der Nachteil dieses Ansatzes besteht darin, dass Ihre Anwendung den umfangreicheren Funktionsumfang der zugrunde liegenden Protokollbibliothek nicht nutzen kann.

Log4j2 bietet eine Lösung, bei der Ihre Anwendung nicht auf den kleinsten gemeinsamen Nenner beschränkt sein muss.

Das Fluchtventil: log4j-to-slf4j

Log4j2 enthält ein log4j-to-slf4j Brückenmodul. Jede Anwendung, die mit der Log4j2-API codiert ist, kann die Sicherungsimplementierung jederzeit auf eine slf4j-kompatible Implementierung umstellen.

log4j-to-slf4j

Wie in der Frage erwähnt, bietet die Verwendung der Log4j2-API direkt mehr Funktionalität und einige nicht-funktionale Vorteile gegenüber der Verwendung einer Wrapper-API wie slf4j:

  • Nachrichten-API
  • Lambdas für faulen Holzeinschlag
  • Protokolliere ein beliebiges Objekt anstatt nur Strings
  • Müllfrei: Vermeiden Sie es, Varargs oder Strings zu erstellen, wo dies möglich ist
  • CloseableThreadContext entfernt Elemente automatisch aus dem MDC, wenn Sie mit ihnen fertig sind

(Weitere Informationen finden Sie unter 10 in SLF4J nicht verfügbare Log4j2-API-Funktionen .)

Anwendungen können diese umfangreichen Funktionen der Log4j2-API sicher nutzen, ohne an die native Log4j2-Kernimplementierung gebunden zu sein.

SLF4J ist immer noch Ihr Sicherheitsventil. Dies bedeutet jedoch nicht, dass Ihre Anwendung nicht mehr mit der SLF4J-API codieren sollte.


Offenlegung: Ich trage zu Log4j2 bei.


Update: Es scheint einige Verwirrung zu geben, dass die Programmierung der Log4j2-API irgendwie eine "Fassade für eine Fassade" einführt. In dieser Hinsicht gibt es keinen Unterschied zwischen der Log4j2-API und SLF4J.

Beide APIs erfordern zwei Abhängigkeiten bei Verwendung einer systemeigenen Implementierung und vier Abhängigkeiten bei einer nicht systemeigenen Implementierung. SLF4J und die Log4j2-API sind in dieser Hinsicht identisch. Zum Beispiel:

Required dependencies are similar for SLF4J and the Log4j 2 API

127
Remko Popma