it-swarm.dev

SLF4J vs LOG4J Welches bevorzugen Sie?

Ich habe dies gesehen Frage aber antwortet mir nicht.

Es hat ein brandneues Projekt. Ich habe fast immer Log4J verwendet, aber jetzt sehe ich, wie SLF4J einige Wellen schlägt. Was konnte Log4J nicht und wir brauchten SLF4J? Ist es wirklich ein Upgrade. Sollte ich es in einem Projekt verwenden, das auch eine API für andere zur Erweiterung enthält?

6
Shahzeb

SLF4J ist im Grunde eine Abstraktionsschicht. Es ist keine Protokollierungsimplementierung. Wenn Sie eine Bibliothek schreiben und SLF4J verwenden, können Sie diese Bibliothek einer anderen Person zur Verwendung geben und diese kann auswählen, welche Protokollierungsimplementierung verwendet werden soll mit SLF4J z. log4j oder die Java-Protokollierungs-API. Sie verhindert, dass Projekte von vielen Protokollierungs-APIs abhängig sind, nur weil sie von ihnen abhängige Bibliotheken verwenden.

Zusammenfassend lässt sich sagen, dass SLF4J log4j nicht ersetzt, sondern zusammenarbeitet. Dadurch wird die Abhängigkeit von log4j aus Ihrer Bibliothek/App entfernt.

Schauen Sie hier: http://www.slf4j.org/ oder sogar hier: http://commons.Apache.org/logging/ (Apache Commons Logging) ähnelt SLF4J) für weitere Informationen zu diesem Konzept.

11

slf4j ist eine API, die entwickelt wurde, um generischen Zugriff auf viele Protokollierungsframeworks zu ermöglichen, und dann mit viel Klebercode, sodass vorhandener Code einfach verwendet werden kann. Welches Sie verwenden, wird dann um Bereitstellungszeit entschieden, nicht wenn Sie Ihren Code schreiben.

Die beste Vorgehensweise besteht heute darin, slf4j für Ihre eigenen Protokollanweisungen zu verwenden und dann das entsprechende Backend dafür auszuwählen. Hier log4j.

Der Hauptgrund für die Migration ist, dass Sie {} in Ihren Nachrichtenzeichenfolgen erhalten, sodass Sie das Konstrukt ifDebug() { log("...") } überspringen können.

3
user1249

Da SLF4j nur eine Protokollierungs-API/-Schnittstelle ist, ersetzt es nicht direkt log4j, ein vollständiges Protokollierungsframework (mit konfigurierbaren Appendern, Filtern usw.), sondern ersetzt Commons Logging als rahmenunabhängige API für die Protokollierung.

SLF4j kann so konfiguriert werden, dass log4j als Protokollierungs-Backend verwendet wird, damit sie zusammenarbeiten können. Ein ziemlich eng verwandtes Projekt ist jedoch logback ( http://logback.qos.ch/ ). Logback ist ein Ersatz für Log4j: Es ist ein Protokollierungsframework (als Log4j), verwendet jedoch nativ die SLF4j-API.

SLF4j verfügt über einige nützliche JAR-Begleitdateien, mit denen andere Protokollierungs-APIs an die SLF4j-API delegiert werden können: jcl-over-slf4j (Ersatz-API, die mit der Commons-Protokollierung kompatibel ist), jul-to-slf4j (für Java.util.logging), log4j-over-slf4j (API kompatibel mit log4j). Wenn Sie diese verwenden, können Sie viele Protokollierungs-APIs mit SLF4j (nützlich für JARs von Drittanbietern) weiterleiten, sodass Sie über ein einziges Protokollierungsframework verfügen, das alle Protokolle verarbeitet.

Die SLF4j-API unterstützt die "MDC" -Funktion von log4j/logback (die in der Commons Logging-API nicht verfügbar ist), sodass Sie diese Funktion in Ihrem Projekt verwenden können, ohne von einem bestimmten Framework abhängig zu sein. Sie können log4j-Aufrufe wahrscheinlich durch SLF4j-Aufrufe in Ihrem Code ersetzen (es sei denn, Sie verwenden andere Funktionen wie NDC), aber Sie möchten wahrscheinlich weiterhin log4j oder slf4j als Backend für die SLF4j-API ausliefern.

1
ysdx