Sollten neue Projekte Logback anstelle von log4j verwenden? [geschlossen]

Sollten neue Projekte Logback anstelle von log4j als Protokollierungsframework verwenden?

Oder mit anderen Worten: "Ist Logback besser als log4j (lassen Sie das SLF4J-Merkmal von Logback daneben)?"

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

Es bietet nette Funktionen wie parametrisierte Nachrichten und (im Gegensatz zur Commons-Protokollierung) einen zugeordneten Diagnosekontext (MDC, Javadoc , Dokumentation ).

Durch die Verwendung von SLF4J kann das Protokollierungs-Backend auf elegante Weise ausgetauscht werden.

Darüber hinaus unterstützt SLF4J die Überbrückung anderer Protokollierungsframeworks mit der tatsächlichen SLF4J-Implementierung, die Sie verwenden, sodass Protokollierungsereignisse von Software von Drittanbietern in Ihren einheitlichen Protokollen angezeigt werden - mit Ausnahme von java.util.logging, das nicht überbrückt werden kann Genauso wie andere Protokollierungsframeworks.

Bridging Jul wird in den Javadocs von SLF4JBridgeHandler erklärt.

Ich habe in mehreren Projekten sehr gute Erfahrungen mit der SLF4J + Logback-Kombination gemacht, und die Entwicklung von LOG4J ist ziemlich ins Stocken geraten.

SLF4J hat die folgenden verbleibenden Nachteile:

• Es werden keine varargs unterstützt, um mit Java <1.5 kompatibel zu bleiben
• Es wird nicht unterstützt, sowohl parametrisierte Nachrichten als auch Ausnahmen gleichzeitig zu verwenden.
• Es enthält keine Unterstützung für einen verschachtelten Diagnosekontext (NDC, javadoc ), den LOG4J hat.

Der Autor (sowohl von Logback als auch von Log4j) hat eine Liste mit Gründen für Änderungen unter http://logback.qos.ch/reasonsToSwitch.html .

Hier sind ein paar, die mir aufgefallen sind;

• Schnellere Implementierung

  Basierend auf unserer vorherigen Arbeit an log4j wurden Logback-Interna neu geschrieben, um auf bestimmten kritischen Ausführungspfaden etwa zehnmal schneller zu arbeiten. Logback-Komponenten sind nicht nur schneller, sie haben auch einen geringeren Speicherbedarf.

• Automatisches Neuladen von Konfigurationsdateien

  Logback-classic kann seine Konfigurationsdatei bei Änderungen automatisch neu laden. Der Scanvorgang ist sowohl schnell als auch sicher, da kein separater Thread zum Scannen erstellt werden muss. Diese technische Subtilität stellt sicher, dass die Rückmeldung auf Anwendungsservern und allgemeiner in der JEE-Umgebung gut funktioniert.

• Spuren mit Verpackungsdaten stapeln

  Wenn Logback eine Ausnahme druckt, enthält die Stapelverfolgung Verpackungsdaten. Hier ist ein Beispiel für eine Stapelverfolgung, die von der Logback-Demo-Webanwendung generiert wurde.

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

  Anhand der obigen Informationen können Sie erkennen, dass die Anwendung Struts Version 1.2.9 verwendet und unter Jetty Version 6.1.12 bereitgestellt wurde. So informieren Stack-Traces den Leser schnell über die in der Ausnahme enthaltenen Klassen, aber auch über das Paket und die Paketversionen, zu denen sie gehören. Wenn Ihre Kunden Ihnen einen Stack-Trace senden, müssen Sie sie als Entwickler nicht mehr bitten, Ihnen Informationen zu den von ihnen verwendeten Versionen von Paketen zu senden. Die Informationen sind Teil des Stack-Trace. Weitere Informationen finden Sie unter "% xThrowable" -Konvertierungswort.

  Diese Funktion kann so hilfreich sein, dass einige Benutzer sie fälschlicherweise als Funktion ihrer IDE betrachten.

• Automatisches Entfernen alter Protokollarchive

  Durch Festlegen der maxHistory-Eigenschaft von TimeBasedRollingPolicy oder SizeAndTimeBasedFNATP können Sie die maximale Anzahl archivierter Dateien steuern. Wenn Ihre fortlaufende Richtlinie einen monatlichen Rollover erfordert und Sie Protokolle im Wert von einem Jahr aufbewahren möchten, setzen Sie einfach die Eigenschaft maxHistory auf 12. Archivierte Protokolldateien, die älter als 12 Monate sind, werden automatisch entfernt.

Es mag dort eine Tendenz geben, aber derselbe Typ hat beide Frameworks geschrieben und wenn er sagt, Logback über Log4j verwenden, ist er es wahrscheinlich wert, angehört zu werden.

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

Dies hat sich für mich als sehr wertvoll erwiesen. Es ermöglicht mir, log4j in alten JVMs und Logback in über 1,5 JVMs sowie bei Bedarf auch java.util.logging zu verwenden.

Logback mehr Java EE-fähig:
Im Allgemeinen (vom Code bis zur Dokumentation) werden Container berücksichtigt - wie mehrere Apps nebeneinander existieren, wie Klassenlader implementiert werden usw. Kontexte für Logger, JNDI, JMX-Konfiguration usw.

Aus der Perspektive eines Entwicklers fügt Logback die parametrisierte Protokollierung hinzu (keine Notwendigkeit, if (logger.isDebugEnabled ()) zu verwenden, um den Aufwand für die Verkettung von Zeichenfolgen zu vermeiden).

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

Das ursprüngliche log4j und logback wurden von demselben Typ entworfen und implementiert.

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

Ich würde denken, dass Ihre Entscheidung auf die gleiche Entscheidung fallen sollte, die Sie treffen würden, wenn Sie sich für die Verwendung von log4j oder Jakarta Commons Logging entscheiden würden. Entwickeln Sie eine Bibliothek, die in anderen Anwendungen enthalten sein wird? Wenn ja, ist es nicht fair, Benutzer Ihrer Bibliothek zu zwingen, auch die Protokollierungsbibliothek Ihrer Wahl zu verwenden.

Wenn die Antwort Nein lautet, würde ich einfach entscheiden, was einfacher hinzuzufügen ist und womit Sie sich besser auskennen. Klingt so, als ob Logback genauso erweiterbar und zuverlässig ist wie log4j. Wenn Sie es also bequem verwenden können, fahren Sie fort.

Ich bin mit SLF4J nicht vertraut und habe mir Logback nur kurz angesehen, aber zwei Dinge fallen mir ein.

Erstens, warum schließen Sie ein Werkzeug von der Prüfung aus? Ich denke, es ist wichtig, offen zu bleiben und alle Möglichkeiten zu prüfen, um die beste zu wählen.

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

Um Ihre Frage zu beantworten - Ja und Nein. Dies hängt vom Projekt ab und davon, wie vertraut das Team mit einem Tool ist. Ich würde nicht sagen, dass Sie log4j nicht verwenden, wenn das gesamte Team damit sehr vertraut ist, alle Anforderungen erfüllt und Logback nichts bietet, was wir zur Erledigung der Aufgabe benötigen.