Frage Sollten neue Projekte Logbuch statt Log4j verwenden? [geschlossen]


Sollten neue Projekte Logging anstelle von log4j als Logging-Framework verwenden?

Oder mit anderen Worten: Ist logback besser als log4j (abgesehen von der SLF4J-Funktion des Logbacks)?


76
2017-10-07 14:55


Ursprung


Antworten:


Sie sollten SLF4J + Logback für die Protokollierung verwenden.

Es bietet übersichtliche Funktionen wie parametrisierte Nachrichten und (im Gegensatz zu Commons-Logging) einen Mapped Diagnostic Context (MDC, Javadoc, Dokumentation).

Die Verwendung von SLF4J macht das Logging-Backend sehr elegant austauschbar.

Zusätzlich SLF4J unterstützt Überbrückung von anderen Logging-Frameworks auf die tatsächliche SLF4J-Implementierung, die Sie verwenden werden, so dass Logging-Ereignisse von Drittanbieter-Software in Ihren Unified Logs angezeigt werden - mit Ausnahme von java.util.logging, das nicht auf die gleiche Weise wie andere Logging-Protokolle gebridged werden kann Rahmen sind.

Bridging jul ist in der erklärt Javadocs von SLF4JBridgeHandler.

Ich hatte eine sehr gute Erfahrung mit der SLF4J + Logback-Kombination in mehreren Projekten und die LOG4J-Entwicklung ist ziemlich ins Stocken geraten.

SLF4J hat die folgenden verbleibenden Nachteile:

  • Es unterstützt nicht Varargs, mit Java <1.5 kompatibel zu bleiben
  • Es unterstützt nicht die gleichzeitige Verwendung einer parametrisierten Nachricht und einer Ausnahme.
  • Es enthält keine Unterstützung für einen geschachtelten Diagnosekontext (NDC, Javadoc) welches LOG4J hat.

81
2018-05-31 22:10



Der Autor (sowohl von Logback als auch von Log4j) hat eine Liste von Gründen, um zu ändern http://logback.qos.ch/reasonsToSwitch.html.

Hier sind ein paar, die auf mich ragten;

  • Schnellere Implementierung

    Basierend auf unserer vorherigen Arbeit an log4j, Logbuch Internals wurden umgeschrieben, um etwa zehn Mal zu spielen schneller bei bestimmter kritischer Ausführung Pfade. Nicht nur Logback Komponenten schneller, sie haben eine kleinerer Speicherabdruck als auch.

  • Automatisches erneutes Laden der Konfiguration Dateien

    Logback-classic kann automatisch Laden Sie seine Konfigurationsdatei erneut auf Änderung. Der Scanvorgang ist so schnell und sicher wie es nicht geht beinhalten die Schaffung eines separaten Thread zum Scannen. Dieses technische Subtilität sorgt dafür, dass das Logback abgespielt wird gut innerhalb der Anwendungsserver und ganz allgemein innerhalb der JEE Umgebung.

  • Stapeln Sie Spuren mit Verpackungsdaten

    Wenn die Protokollierung eine Ausnahme ausgibt, wird die Stack-Trace enthält Verpackung Daten. Hier ist eine Beispiel-Stack-Trace generiert von der Logback-Demo Internetanwendung.

    14: 28: 48.835 [btpool0-7] INFO c.q.l.demo.prime.PrimeAction - 99 ist kein gültiger Wert java.lang.Exception: 99 ist ungültig
    beim ch.qos.logback.demo.prime.PrimeAction.execute (PrimeAction.java:28) [Klassen /: na] bei org.apache.struts.action.RequestProcessor.processActionPerform (RequestProcessor.java:431) [struts-1.2.9.jar: 1.2.9] bei org.apache.struts.action.RequestProcessor.process (RequestProcessor.java:236) [struts-1.2.9.jar: 1.2.9] bei org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:432) [struts-1.2.9.jar: 1.2.9] bei javax.servlet.http.HttpServlet.service (HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar: 6.1.12]
    beim org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:502) [Anlegestelle-6.1.12.jar: 6.1.12] um ch.qos.logback.demo.UserServletFilter.doFilter (UserServletFilter.java:44) [Klassen /: na] bei org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter (ServletHandler.java:1115) [Anlegestelle-6.1.12.jar: 6.1.12] um org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:361) [Anlegestelle-6.1.12.jar: 6.1.12] um org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:417) [Anlegestelle-6.1.12.jar: 6.1.12] um org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:230) [jetty-6.1.12.jar: 6.1.12]

    Von dem oben genannten können Sie erkennen dass die Anwendung Struts verwendet Version 1.2.9 und wurde unter bereitgestellt Stegversion 6.1.12. Also, stapeln Spuren werden den Leser schnell informieren über die Klassen in der Ausnahme aber auch das Paket und Paketversionen, zu denen sie gehören. Wann Ihre Kunden senden Ihnen einen Stapel verfolgen, als Entwickler werden Sie nicht länger müssen Sie sie bitten, Sie zu senden Informationen zu den Versionen von Pakete, die sie verwenden. Das Informationen werden Teil des Stapels sein Spur. Siehe "% xThrowable" Konvertierung Wort für Details.

    Diese Funktion kann sehr hilfreich sein der Punkt, dass einige Benutzer irrtümlich Betrachten Sie es als ein Feature ihrer IDE.

  • Automatisches Entfernen alter Log-Archive

    Durch Festlegen der maxHistory-Eigenschaft von TimeBasedRollingPolicy oder SizeAndTimeBasedFNATP, können Sie Kontrolliere die maximale Anzahl von archivierte Dateien. Wenn du rollst Richtlinie fordert monatliches Rollover und Sie möchten ein Jahr halten logs, setzen Sie einfach den maxHistory Eigenschaft zu 12. Archivierte Protokolldateien älter als 12 Monate werden automatisch entfernt

Es mag da eine Voreingenommenheit geben, aber derselbe Typ hat beide Frameworks geschrieben und wenn er sagt loglog über Log4j zu benutzen, ist er wahrscheinlich hörenswert.


20
2018-05-18 12:27



Ich würde slf4j für die Anmeldung in allen Fällen verwenden. Auf diese Weise können Sie auswählen, welches tatsächliche Logging-Backend Sie verwenden möchten, und zwar zur Bereitstellungszeit anstelle der Codezeit.

Dies hat sich für mich als sehr wertvoll erwiesen. Es erlaubt mir, log4j in alten JVMs zu verwenden, und loggen Sie in 1.5+ JVMs und java.util.logging, wenn nötig, ein.


10
2018-01-20 12:47



Logbuch mehr Java EE aware:
Im Allgemeinen (vom Code bis zur Dokumentation) behalte ich Container im Auge - wie mehrere Apps nebeneinander existieren, wie Klassenladeprogramme implementiert werden usw. Kontexte für Logger, JNDI, JMX-Konfiguration usw.

Von Entwickler prospektiv fast gleich, Logback fügt hinzu Parametrisierte Protokollierung (keine Verwendung von if (logger.isDebugEnabled ()) zur Vermeidung von String-Verkettungs-Overhead)

Log4j - nur Riese Plus ist alte JVM-Unterstützung, klein (IMO) NDC (Logback nur MDC), einige Erweiterungen. Zum Beispiel habe ich eine Extension für configureAndWatch für Log4j geschrieben, keine solche für Logback


2
2018-04-22 17:02



Das Original Log4j und Logback wurden von demselben Typen entworfen und implementiert.

Mehrere Open-Source-Tools haben SLF4J verwendet. Ich sehe keine wesentlichen Mängel in diesem Tool. Wenn Sie also in Ihrer Codebasis nicht viele Erweiterungen zu log4j haben, würde ich mit Logback fortfahren.


1
2017-10-07 15:08



Ich würde denken, dass Ihre Entscheidung die gleiche Entscheidung treffen sollte, wenn Sie sich für die Verwendung von log4j oder Jakarta Commons Logging entscheiden - entwickeln Sie eine Bibliothek, die in anderen Anwendungen enthalten sein wird? Wenn dem so ist, dann scheint es nicht fair zu sein, Benutzer Ihrer Bibliothek dazu zu zwingen, auch Ihre bevorzugte Logging-Bibliothek zu verwenden.

Wenn die Antwort nein ist, würde ich einfach mit dem gehen, was einfacher hinzuzufügen ist und mit dem Sie sich wohler fühlen. Klingt wie Logback ist genauso erweiterbar und zuverlässig wie log4j, also wenn Sie es bequem verwenden, gehen Sie voran.


1
2017-10-07 15:50



Ich bin mit SLF4J nicht vertraut und habe Logback nur kurz angeschaut, aber zwei Dinge kommen mir in den Sinn.

Erstens, warum schließen Sie ein Werkzeug von der Untersuchung aus? Ich denke, es ist wichtig, offen zu bleiben und alle Möglichkeiten zu prüfen, um den besten auszuwählen.

Zweitens denke ich, dass in einigen Projekten ein Werkzeug besser ist als ein anderes, und dass das Gegenteil in einem anderen Projekt der Fall sein könnte. Ich glaube nicht, dass ein Werkzeug immer besser ist als ein anderes Werkzeug. Es gibt schließlich keine Silberkugel.

Um deine Frage zu beantworten - Ja und Nein. Es hängt vom Projekt ab und wie vertraut das Team mit einem Werkzeug ist. Ich würde nicht sagen "Log4j nicht verwenden", wenn das gesamte Team sehr gut damit zurechtkommt, es alle Bedürfnisse erfüllt, und Logback bietet nichts, was wir brauchen, um die Aufgabe abzuschließen.


-3
2017-10-07 14:58