logback klingt sehr ähnlich wie jakarta commons logging - was sind die Hauptunterschiede?
Matt B
12
SLF4J (die Fassade) klingt ähnlich wie commons.logging. Der Hauptunterschied besteht darin, dass SLF4J eine statische Bindung verwendet, während commons.logging eine Auflösungsstrategie verwendet. Logback (die "native" Implementierung (dh es gibt keine zusätzliche Wrapper-Schicht) der Fassade) ist vergleichbar mit LOG4J, verfügt jedoch über eine umfangreichere API.
Huxi
Antworten:
190
Logback implementiert nativ die SLF4J-API. Dies bedeutet, dass Sie bei Verwendung von Logback tatsächlich die SLF4J-API verwenden. Sie könnten theoretisch die Interna der Logback-API direkt für die Protokollierung verwenden, aber davon wird dringend abgeraten. Alle Logback-Dokumentationen und Beispiele zu Loggern sind in Bezug auf die SLF4J-API geschrieben.
Wenn Sie also logback verwenden, würden Sie tatsächlich SLF4J verwenden. Wenn Sie aus irgendeinem Grund wieder zu log4j wechseln möchten, können Sie dies innerhalb von Minuten tun, indem Sie einfach slf4j-log4j12.jar auf Ihren Klassenpfad legen.
Bei der Migration von logback zu log4j müssen logback-spezifische Teile, insbesondere die in der Konfigurationsdatei logback.xml enthaltenen, weiterhin auf das entsprechende log4j- Element , dh log4j.properties , migriert werden . Bei einer Migration in die andere Richtung müsste die log4j-Konfiguration, dh log4j.properties , in das Logback-Äquivalent konvertiert werden. Dafür gibt es ein Online-Tool . Der Arbeitsaufwand für die Migration von Konfigurationsdateien ist viel geringer als der Aufwand für die Migration von Logger-Aufrufen, die im gesamten Quellcode Ihrer Software und deren Abhängigkeiten verteilt sind.
Ist es schmerzlos? Wahrscheinlich, aber es kann von Ihren Protokollierungsanweisungen abhängen.
Beachten Sie, dass Sie, wenn Sie LogBack (oder SLF4J) wirklich voll ausnutzen möchten, wirklich die richtigen Protokollierungsanweisungen schreiben müssen . Dies bietet Vorteile wie schnelleren Code aufgrund der verzögerten Auswertung und weniger Codezeilen, da Sie Wachen vermeiden können.
Schließlich empfehle ich SLF4J. (Warum das Rad mit Ihrer eigenen Fassade nachbauen?)
Hinweis: Das log4j-Projekt betrachtet log4j nicht als veraltet.
Thorbjørn Ravn Andersen
17
Die Terminologie sollte geklärt werden; Der Autor des log4j-Projekts betrachtet logback eindeutig als Nachfolger von log4j. Es ist derselbe Autor beider Projekte, daher sollte seine Meinung etwas Gewicht haben. Das "log4j-Projekt" selbst "berücksichtigt" eigentlich nichts. Die aktuelle Gruppe von Personen, die mit log4j in Verbindung stehen, hat unterschiedliche Meinungen (einige stimmen tatsächlich zu, andere nicht überraschend). Mit etwas mehr Geschichte hinter uns (3 Jahre nach dem ursprünglichen Kommentar) gewinnt SLF4J + Logback gegenüber Log4j weiter an Boden.
Michael
@michael_n Bitte beachten Sie, dass Log4j 1 NICHT von einer einzelnen Person geschrieben wurde. Es ist falsch, den "gleichen Autor" zu sagen. Ceki ist zweifellos ein wichtiger Autor, aber nicht der einzige. Tatsächlich haben viele Leute geholfen, Log4j 1 zu dem zu machen, was es ist.
Christian
@Christian "wurde NICHT geschrieben ...", das sollte natürlich für jedes ausgereifte Apache-Projekt impliziert werden (und meine Qualifikation "die aktuelle Gruppe von Personen, die mit log4j assoziiert sind"); Wenn ich den Kommentar bearbeiten könnte, würde ich dennoch " ursprünglich verfasst" sagen , wie es auch im Wikipedia-Artikel heißt. Betreff: "Tatsächlich haben viele Leute dazu beigetragen, Log4j 1 zu dem zu machen, was es ist" , das ist absolut eindeutig (dh zum Guten oder Schlechten); und auch in gewisser Weise zur Entstehung von slf4j + logback beigetragen :-)
michael
3
Also, was haben Sie alle vor, um über diese oder jene Protokollierungsbibliothek zu streiten? Warum versuchen wir, Bibliotheken zu töten / zu fördern? Geben Sie zumindest einige rationale Gründe an, WARUM eines besser ist als das andere. Gott, Stapelüberlauf ist ein Chaos.
Benutzer
48
In der Protokollierungswelt gibt es Fassaden (wie Apache Commons Logging, slf4j oder sogar die Log4j 2.0-API) und Implementierungen (Log4j 1 + 2, java.util.logging, TinyLog, Logback).
Grundsätzlich sollten Sie Ihren selbstgemachten Wrapper durch slf4j IF ersetzen und nur, wenn Sie aus irgendeinem Grund nicht damit zufrieden sind. Während Apache Commons Logging nicht wirklich eine moderne API bietet, bieten slf4j und die neue Log4j 2-Fassade dies. Angesichts der Tatsache, dass eine ganze Reihe von Apps slf4j als Wrapper verwenden, ist es möglicherweise sinnvoll, dies zu verwenden.
slf4j bietet eine Reihe netter API-Zucker, wie dieses Beispiel aus slf4j-Dokumenten:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
Es ist eine variable Substitution. Dies wird auch von Log4j 2 unterstützt.
Sie müssen sich jedoch darüber im Klaren sein, dass slf4j von QOS entwickelt wurde, die auch die Rückmeldung beibehalten. Log4j 2.0 wird in der Apache Software Foundation gebacken. In den letzten drei Jahren ist dort wieder eine lebendige und aktive Gemeinschaft gewachsen. Wenn Sie Open Source schätzen, wie es von der Apache Software Foundation mit all ihren Garantien durchgeführt wird, können Sie die Verwendung von slf4j für die direkte Verwendung von Log4j 2 überdenken.
Bitte beachten Sie:
In der Vergangenheit wurde log4j 1 nicht aktiv gepflegt, während Logback aktiv war. Aber heute ist das anders. Log4j 2 wird aktiv gewartet und fast regelmäßig veröffentlicht. Es enthält auch viele moderne Funktionen und -imho- macht ein paar Dinge besser als Logback. Dies ist manchmal nur eine Frage des Geschmacks und Sie sollten Ihre eigenen Schlussfolgerungen ziehen.
Beim Lesen werden Sie feststellen, dass Log4j 2 von Logback, aber auch von anderen Protokollierungsframeworks inspiriert wurde. Die Codebasis ist jedoch anders. Es teilt fast nichts mit Log4j 1 und Null mit Logback. Dies führte zu einigen Verbesserungen, wie in Beispiel Log4j 2, das mit Bytestreams anstelle von Strings unter der Haube arbeitet. Außerdem werden beim Neukonfigurieren keine Ereignisse verloren.
Die beste Idee ist jedoch, dass Sie die Protokollierungs-Frameworks auswählen, die am besten zu dem passen, was Sie erreichen möchten. Ich würde kein vollständiges Framework wechseln, wenn ich die Protokollierung in der Produktionsumgebung deaktivieren und nur die grundlegende Protokollierung in meiner App durchführen würde. Wenn Sie jedoch etwas mehr mit der Protokollierung tun, schauen Sie sich einfach die Funktionen an, die von den Frameworks und ihren Entwicklern bereitgestellt werden. Während Sie über QOS kommerziellen Support für Logback erhalten (wie ich gehört habe), gibt es derzeit keinen kommerziellen Support für Log4j 2. Wenn Sie jedoch eine Audit-Protokollierung durchführen müssen und eine hohe Leistung der asynchronen Appender benötigen, ist dies sehr sinnvoll Überprüfen Sie log4j 2.
Bitte beachten Sie, dass Fassaden trotz ihres Komforts immer ein wenig Leistung bringen. Es betrifft Sie vielleicht überhaupt nicht, aber wenn Sie wenig Ressourcen haben, müssen Sie möglicherweise alles speichern, was Sie haben können.
Ohne Ihre Anforderungen besser zu kennen, ist es fast unmöglich, eine Empfehlung abzugeben. Nur: Wechseln Sie nicht, nur weil viele Leute wechseln. Wechseln Sie nur, weil Sie den Wert davon sehen. Und die Argumentation, dass log4j tot ist, zählt nicht mehr. Es lebt und es ist heiß.
HAFTUNGSAUSSCHLUSS: Ich bin derzeit VP, Apache Logging Services und auch an log4j beteiligt.
Sie beantworten Ihre Frage nicht genau, aber wenn Sie sich von Ihrem selbst erstellten Wrapper entfernen könnten, gibt es die Simple Logging Facade für Java (SLF4J), auf die Hibernate jetzt umgestellt hat (anstelle der allgemeinen Protokollierung).
SLF4J leidet unter keinem der bei Jakarta Commons Logging (JCL) beobachteten Probleme mit dem Klassenladeprogramm oder Speicherlecks.
SLF4J unterstützt JDK-Protokollierung, log4j und Protokollierung. Dann sollte es ziemlich einfach sein, zum richtigen Zeitpunkt von log4j zu logback zu wechseln.
Edit: Aplogien, die ich mir nicht klar gemacht hatte. Ich schlug vor, SLF4J zu verwenden, um zu verhindern, dass Sie eine schwierige Wahl zwischen log4j oder logback treffen müssen.
Ich kenne SLF4J. Aber ich habe nach dem Protokollierungsrahmen gefragt, nicht nach der Fassade!
4
Entschuldigung. Ich schlug vor, dass der Wechsel von log4j zu logback weniger schmerzhaft wäre, wenn Sie SLF4J anstelle Ihrer eigenen Fassade verwenden würden.
Toolkit
Was ist die Quelle dieses Zitats? Die Commons-Protokollierung ist eine bewährte Komponente. Ich hatte noch nie Speicherlecks.
Kshitiz Sharma
1
@ KshitizSharma - über den SLF4J-Dokumentationslink, den ich bereitgestellt habe: slf4j.org/manual.html
Toolkit
13
Ihre Entscheidung sollte auf basieren
Ihr tatsächlicher Bedarf an diesen "mehr Funktionen"; und
Ihre erwarteten Kosten für die Implementierung der Änderung.
Sie sollten dem Drang widerstehen, APIs zu ändern, nur weil sie "neuer, glänzender, besser" sind. Ich folge der Politik: "Wenn es nicht kaputt ist, tritt es nicht."
Wenn für Ihre Anwendung ein sehr ausgeklügeltes Protokollierungsframework erforderlich ist, sollten Sie sich überlegen, warum.
Ein ausgereiftes Projekt oder sogar ein Projekt tief in der Entwicklungsphase würde wahrscheinlich mehr als nur einen Gewinn aus einem solchen Upgrade verlieren, IMHO. Logback ist in einer Reihe von Punkten sicherlich viel weiter fortgeschritten, jedoch nicht in einem Ausmaß, in dem es in einem funktionierenden System vollständig ersetzt werden kann. Ich würde sicherlich ein Logback für eine neue Entwicklung in Betracht ziehen, aber das vorhandene log4j ist gut genug und ausgereift für alles, was bereits veröffentlicht wurde und den Endbenutzer traf. Das ist sehr subjektiv, das sollten Sie selbst kosten.
Antworten:
Logback implementiert nativ die SLF4J-API. Dies bedeutet, dass Sie bei Verwendung von Logback tatsächlich die SLF4J-API verwenden. Sie könnten theoretisch die Interna der Logback-API direkt für die Protokollierung verwenden, aber davon wird dringend abgeraten. Alle Logback-Dokumentationen und Beispiele zu Loggern sind in Bezug auf die SLF4J-API geschrieben.
Wenn Sie also logback verwenden, würden Sie tatsächlich SLF4J verwenden. Wenn Sie aus irgendeinem Grund wieder zu log4j wechseln möchten, können Sie dies innerhalb von Minuten tun, indem Sie einfach slf4j-log4j12.jar auf Ihren Klassenpfad legen.
Bei der Migration von logback zu log4j müssen logback-spezifische Teile, insbesondere die in der Konfigurationsdatei logback.xml enthaltenen, weiterhin auf das entsprechende log4j- Element , dh log4j.properties , migriert werden . Bei einer Migration in die andere Richtung müsste die log4j-Konfiguration, dh log4j.properties , in das Logback-Äquivalent konvertiert werden. Dafür gibt es ein Online-Tool . Der Arbeitsaufwand für die Migration von Konfigurationsdateien ist viel geringer als der Aufwand für die Migration von Logger-Aufrufen, die im gesamten Quellcode Ihrer Software und deren Abhängigkeiten verteilt sind.
quelle
Sollten Sie? Ja .
Warum? Log4J wurde von Logback im Wesentlichen veraltet .
Es ist dringend? Vielleicht nicht.
Ist es schmerzlos? Wahrscheinlich, aber es kann von Ihren Protokollierungsanweisungen abhängen.
Beachten Sie, dass Sie, wenn Sie LogBack (oder SLF4J) wirklich voll ausnutzen möchten, wirklich die richtigen Protokollierungsanweisungen schreiben müssen . Dies bietet Vorteile wie schnelleren Code aufgrund der verzögerten Auswertung und weniger Codezeilen, da Sie Wachen vermeiden können.
Schließlich empfehle ich SLF4J. (Warum das Rad mit Ihrer eigenen Fassade nachbauen?)
quelle
In der Protokollierungswelt gibt es Fassaden (wie Apache Commons Logging, slf4j oder sogar die Log4j 2.0-API) und Implementierungen (Log4j 1 + 2, java.util.logging, TinyLog, Logback).
Grundsätzlich sollten Sie Ihren selbstgemachten Wrapper durch slf4j IF ersetzen und nur, wenn Sie aus irgendeinem Grund nicht damit zufrieden sind. Während Apache Commons Logging nicht wirklich eine moderne API bietet, bieten slf4j und die neue Log4j 2-Fassade dies. Angesichts der Tatsache, dass eine ganze Reihe von Apps slf4j als Wrapper verwenden, ist es möglicherweise sinnvoll, dies zu verwenden.
slf4j bietet eine Reihe netter API-Zucker, wie dieses Beispiel aus slf4j-Dokumenten:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);Es ist eine variable Substitution. Dies wird auch von Log4j 2 unterstützt.
Sie müssen sich jedoch darüber im Klaren sein, dass slf4j von QOS entwickelt wurde, die auch die Rückmeldung beibehalten. Log4j 2.0 wird in der Apache Software Foundation gebacken. In den letzten drei Jahren ist dort wieder eine lebendige und aktive Gemeinschaft gewachsen. Wenn Sie Open Source schätzen, wie es von der Apache Software Foundation mit all ihren Garantien durchgeführt wird, können Sie die Verwendung von slf4j für die direkte Verwendung von Log4j 2 überdenken.
Bitte beachten Sie:
In der Vergangenheit wurde log4j 1 nicht aktiv gepflegt, während Logback aktiv war. Aber heute ist das anders. Log4j 2 wird aktiv gewartet und fast regelmäßig veröffentlicht. Es enthält auch viele moderne Funktionen und -imho- macht ein paar Dinge besser als Logback. Dies ist manchmal nur eine Frage des Geschmacks und Sie sollten Ihre eigenen Schlussfolgerungen ziehen.
Ich habe einen kurzen Überblick über die neuen Funktionen von Log4j 2.0 geschrieben: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html
Beim Lesen werden Sie feststellen, dass Log4j 2 von Logback, aber auch von anderen Protokollierungsframeworks inspiriert wurde. Die Codebasis ist jedoch anders. Es teilt fast nichts mit Log4j 1 und Null mit Logback. Dies führte zu einigen Verbesserungen, wie in Beispiel Log4j 2, das mit Bytestreams anstelle von Strings unter der Haube arbeitet. Außerdem werden beim Neukonfigurieren keine Ereignisse verloren.
Log4j 2 kann mit höherer Geschwindigkeit als andere mir bekannte Frameworks protokollieren: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
Und dennoch scheint die Benutzergemeinschaft viel größer zu sein als Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html
Die beste Idee ist jedoch, dass Sie die Protokollierungs-Frameworks auswählen, die am besten zu dem passen, was Sie erreichen möchten. Ich würde kein vollständiges Framework wechseln, wenn ich die Protokollierung in der Produktionsumgebung deaktivieren und nur die grundlegende Protokollierung in meiner App durchführen würde. Wenn Sie jedoch etwas mehr mit der Protokollierung tun, schauen Sie sich einfach die Funktionen an, die von den Frameworks und ihren Entwicklern bereitgestellt werden. Während Sie über QOS kommerziellen Support für Logback erhalten (wie ich gehört habe), gibt es derzeit keinen kommerziellen Support für Log4j 2. Wenn Sie jedoch eine Audit-Protokollierung durchführen müssen und eine hohe Leistung der asynchronen Appender benötigen, ist dies sehr sinnvoll Überprüfen Sie log4j 2.
Bitte beachten Sie, dass Fassaden trotz ihres Komforts immer ein wenig Leistung bringen. Es betrifft Sie vielleicht überhaupt nicht, aber wenn Sie wenig Ressourcen haben, müssen Sie möglicherweise alles speichern, was Sie haben können.
Ohne Ihre Anforderungen besser zu kennen, ist es fast unmöglich, eine Empfehlung abzugeben. Nur: Wechseln Sie nicht, nur weil viele Leute wechseln. Wechseln Sie nur, weil Sie den Wert davon sehen. Und die Argumentation, dass log4j tot ist, zählt nicht mehr. Es lebt und es ist heiß.
HAFTUNGSAUSSCHLUSS: Ich bin derzeit VP, Apache Logging Services und auch an log4j beteiligt.
quelle
Sie beantworten Ihre Frage nicht genau, aber wenn Sie sich von Ihrem selbst erstellten Wrapper entfernen könnten, gibt es die Simple Logging Facade für Java (SLF4J), auf die Hibernate jetzt umgestellt hat (anstelle der allgemeinen Protokollierung).
SLF4J unterstützt JDK-Protokollierung, log4j und Protokollierung. Dann sollte es ziemlich einfach sein, zum richtigen Zeitpunkt von log4j zu logback zu wechseln.
Edit: Aplogien, die ich mir nicht klar gemacht hatte. Ich schlug vor, SLF4J zu verwenden, um zu verhindern, dass Sie eine schwierige Wahl zwischen log4j oder logback treffen müssen.
quelle
Ihre Entscheidung sollte auf basieren
Sie sollten dem Drang widerstehen, APIs zu ändern, nur weil sie "neuer, glänzender, besser" sind. Ich folge der Politik: "Wenn es nicht kaputt ist, tritt es nicht."
Wenn für Ihre Anwendung ein sehr ausgeklügeltes Protokollierungsframework erforderlich ist, sollten Sie sich überlegen, warum.
quelle
Ein ausgereiftes Projekt oder sogar ein Projekt tief in der Entwicklungsphase würde wahrscheinlich mehr als nur einen Gewinn aus einem solchen Upgrade verlieren, IMHO. Logback ist in einer Reihe von Punkten sicherlich viel weiter fortgeschritten, jedoch nicht in einem Ausmaß, in dem es in einem funktionierenden System vollständig ersetzt werden kann. Ich würde sicherlich ein Logback für eine neue Entwicklung in Betracht ziehen, aber das vorhandene log4j ist gut genug und ausgereift für alles, was bereits veröffentlicht wurde und den Endbenutzer traf. Das ist sehr subjektiv, das sollten Sie selbst kosten.
quelle