Was ist los mit der Anmeldung in Java? [geschlossen]

Warum sollte man eines der folgenden Pakete anstelle des anderen verwenden?

• Java-Protokollierung
• Commons-Protokollierung
• Log4j
• SLF4j
• Wieder anmelden

In chronologischer Reihenfolge des Erscheinungsbilds (soweit ich weiß):

• Log4j, weil es fast jeder benutzt (meiner Erfahrung nach)
• Commons Logging, weil Open Source-Projekte es verwenden (damit sie sich in jedes Protokollierungsframework integrieren können, das in der integrierten Lösung verwendet wird); Dies gilt insbesondere dann, wenn Sie eine API / Framework / OSS sind und sich auf andere Pakete verlassen, die Commons Logging verwenden.
• Commons-Protokollierung, weil Sie nicht an ein bestimmtes Protokollierungsframework "sperren" möchten (stattdessen sperren Sie stattdessen an das, was Ihnen die Commons-Protokollierung bietet) - Ich halte es nicht für sinnvoll, diesen Punkt als Grund zu verwenden.
• Java-Protokollierung, da Sie kein zusätzliches Glas hinzufügen möchten.
• SLF4j, weil es neuer als Commons Logging ist und parametrisierte Protokollierung bietet:

logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
    // Note that it's actually *more* efficient than this - see Huxi's comment below...
    logger.debug("The entry is " + entry + "."); 
}

• Logback, da es neuer als log4j ist und erneut die parametrisierte Protokollierung unterstützt, da SLF4j direkt implementiert wird
• SLF4j / Logback, weil es von demselben Typ geschrieben wurde, der log4j gemacht hat, also hat er es besser gemacht (laut Ken G - danke. Es scheint zu passen, wenn man sich ihre früheren Nachrichten ansieht ).
• SLF4j, da sie auch einen log4j-Adapter veröffentlichen, sodass Sie log4j in älterem Code nicht "ausschalten" müssen - lassen Sie log4j.properties einfach SLF4j und dessen Konfiguration verwenden

Ich finde die Anmeldung in Java verwirrend, inkonsistent, schlecht dokumentiert und besonders zufällig. Darüber hinaus gibt es eine große Ähnlichkeit zwischen diesen Protokollierungsframeworks, was zu Doppelarbeit und Verwirrung darüber führt, in welcher Protokollierungsumgebung Sie sich tatsächlich befinden. Insbesondere wenn Sie in einem seriösen Java-Webanwendungsstapel arbeiten, befinden Sie sich häufig in mehrereProtokollieren von Umgebungen auf einmal; (z. B. kann der Ruhezustand log4j und tomcat java.util.logging verwenden). Apache Commons soll verschiedene Protokollierungsframeworks überbrücken, erhöht jedoch die Komplexität. Wenn Sie dies nicht im Voraus wissen, ist es äußerst verwirrend. Warum werden meine Protokollnachrichten nicht auf der Konsole usw. gedruckt? Ohh, weil ich mir die Tomcat-Protokolle ansehe und nicht log4j. Der Anwendungsserver verfügt möglicherweise über globale Protokollierungskonfigurationen, die lokale Konfigurationen für eine bestimmte Webanwendung möglicherweise nicht erkennen. Schließlich sind alle diese Protokollierungs-Frameworks viel zu kompliziert. Das Anmelden in Java war ein unorganisiertes Durcheinander, das Entwickler wie mich frustriert und verwirrt machte.

Frühere Java-Versionen verfügten nicht über ein integriertes Protokollierungsframework, das zu diesem Szenario führte.

Es gibt einen wichtigen Punkt, der zuvor nicht erwähnt wurde:

SLF4J (und sowohl Logback als auch LOG4J als Protokollierungs-Backend) unterstützen einen sogenannten Mapped Diagnostic Context (MDC, siehe Javadoc und Dokumentation ).

Dies ist im Wesentlichen eine threadlokale Map <String, String>, mit der Sie Ihrem Protokollierungsereignis zusätzliche Kontextinformationen hinzufügen können. Der aktuelle Status des MDC ist jedem Ereignis zugeordnet.

Dies kann unglaublich nützlich sein, wenn Sie Dinge wie den Benutzernamen und die URL der Anfrage (im Falle einer Webanwendung) einfügen. Dies kann beispielsweise automatisch mit einem Filter erfolgen.

Siehe auch Antworten auf die Frage Was sind die besten Methoden, um einen Fehler zu protokollieren? , insbesondere:

• Es gibt einige potenzielle Probleme beim Laden von Klassen mit Commons Logging.

• Log4J und SLF4J wurden von derselben Person entwickelt und lernten aus Problemen, die in der Praxis mit Log4J aufgetreten sind.

In unserem Unternehmensprojekt verwenden wir LOG4j und es ist sehr einfach zu verwenden, wie Stephen in seinem Beispiel gezeigt hat. Wir haben auch eigene Musterklassen für LOG4j geschrieben, damit Sie Ihre eigenen Ausgabedateischemata erstellen können. Sie können beschreiben, wie Ihre Protokolldatei aussehen soll. Es ist möglich, die ursprünglichen log4j-Klassen zu erweitern.

Alle LOG4j-Eigenschaften, die Sie in einer log4j.properties-Datei ändern können, sodass Sie unterschiedliche Dateien für unterschiedliche Projekte verwenden können.

Java-Protokollierung ist nicht mein Favorit, aber das könnte daran liegen, dass ich log4j von Anfang an verwende.

Die Commons-Protokollierungsübersicht gibt den Grund für ihre Existenz an: Protokollierung aus Bibliothekscode, wenn Sie keine Kontrolle über das zugrunde liegende Protokollierungsframework haben. Sehr wichtig für die verschiedenen Apache-Projekte, die mit externen Anwendungen verknüpft werden. Vielleicht nicht so wichtig für interne IT-Projekte, bei denen Sie die vollständige Kontrolle haben.

Trotzdem schreibe ich an Commons Logging, ebenso wie viele andere Entwickler, die ich kenne. Der Grund ist, das mentale Gepäck zu minimieren: Sie können Projekte oder Jobs ändern und müssen kein neues Framework erlernen (vorausgesetzt, der neue Job / das neue Projekt verwendet auch CL und / oder Sie können sie davon überzeugen, dorthin zu wechseln).

Es ist auch sinnvoll, eigene Wrapper für das von Ihnen verwendete Framework zu erstellen. Wie hier beschrieben , verwende ich gerne ein LogWrapper-Objekt, um eine benutzerdefinierte Zeichenfolge bereitzustellen (wichtig) und die visuelle Unordnung von Protokollierungsanweisungen zu minimieren (weniger wichtig).

Im Allgemeinen würde ich standardmäßig Log4J verwenden.

Ich würde Java Logging verwenden, wenn mir eine Abhängigkeit von Java 1.4 nichts ausmachen würde, aber ich würde weiterhin bevorzugt Log4J verwenden.

Ich würde Commons Logging verwenden, wenn ich etwas verbessern würde, das es bereits verwendet.

Ich würde vorschlagen, eine dünne Protokollierungsfassade zu erstellen, die in jedes der Protokollierungsframeworks schreiben kann. Ab diesem Zeitpunkt wird die Wahl der Backing-Engine zu einem strittigen Punkt.