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.