Lohnt es sich, ein Protokollierungsframework in eine zusätzliche Ebene einzufügen?

Question

Ich bin gerade dabei, den Logging-Mechanismus in einer mittleren bis großen Java-Codebasis zu aktualisieren. Nachrichten werden derzeit mit statischen Methoden in einer Debug Klasse protokolliert, und ich habe empfohlen, von dieser zu etwas wie SLF4J oder Commons-Logging zu wechseln.

Der Anwendungsarchitekt bevorzugt, dass ich die Abhängigkeit von SLF4J verkapsele (möglicherweise indem ich es in der oben erwähnten Debug-Klasse einpacke). Dadurch wird es einfacher, die Protokollierungsimplementierung in der Zukunft zu ändern.

Dies scheint für mich zu übertrieben, da SLF4J bereits die konkrete Protokollimplementierung abstrahiert.

Lohnt es sich, eine Logging-Abstraktion von Drittanbietern wie SLF4J in eine andere eingewachsene Abstraktion einzuwickeln?

Answer 1

Ich stimme Ihnen vollkommen zu: Wrapper von Wrappern von Wrappers geraten außer Kontrolle. Ich vermute, dass der Architekt nicht weiß, wie SLF4J insbesondere jedes andere Logging-System leicht umhüllen kann, so dass "eine Änderung der Implementierung" ohne eine weitere Schicht von Wrappage durchaus möglich ist.

Answer 2

Wenn Sie Logging-Frameworks in der Zukunft wechseln möchten, kann es sich lohnen, eine zusätzliche Ebene hinzuzufügen, wo Sie den Logger ausschalten können. Andernfalls, wenn sie alles liefern, was Sie möglicherweise brauchen werden (natürlich mit Ihrer Kristallkugel), dann ist es wahrscheinlich in Ordnung, eine harte Abhängigkeit von diesem Rahmen zu haben.

Wenn Ihre aktuelle Konfiguration Flexibilität zu ändern erlaubt, benötigen Sie keinen Wrapper.

Answer 3

Erklären Sie Ihrem Architecture Astronaut, dass slf4j bereits als Wrapper für andere Logging-Implementierungen wie Log4j dienen kann. Wenn Sie also in Zukunft einen anderen Logger verwenden müssen und es keinen Adapter für slf4j gibt, können Sie ihn schreiben, wenn es notwendig ist, aber es wird nur der Adapter sein, anstatt ein ganzes Logging-Framework zu schreiben, das nur einige andere umschließt Logging Framework und Sie müssen Ihr Framework dafür entwerfen und schreiben Sie Ihren eigenen Adapter.

Answer 4

Ich würde es vorziehen, es zu wickeln, aber nicht aus dem angegebenen Grund. Wenn es sich um die Möglichkeit handelt, ein anderes Framework auszutauschen, verwenden Sie java.util.logging oder SLF (java.util.logging ist nicht so einfach zu verwenden wie ein Wrapper, aber es ist durchaus machbar), und tauschen Sie es aus. Der Grund dafür, einen weiteren Wrapper zu verwenden, besteht darin, die geeignete Art der Protokollierung im Code zu kodieren. Im Allgemeinen möchte eine Anwendung eine Teilmenge, z. B. alle Systemfehler, mit einer Ausnahme oder spezifische Anweisungen dazu, wann die Standardprotokollierungsstufen verwendet werden sollen. Diese Entscheidungen können in wenigen Methoden gekapselt werden, um konsistentere Protokollierungsentscheidungen über eine große Codebasis zu erstellen.

Wenn jedoch die Motivation nur darin besteht, Implementierungen auszutauschen, erfinden Sie das Rad nicht neu. SLF ist perfekt für den Job, benutze es einfach.

Es gibt eine Ausnahme. Wenn Ihr Code nahtlos in viele mögliche App-Server implementiert werden soll, müssen Sie sicherstellen, dass Ihre Protokollierungsoption nicht in Konflikt mit möglicherweise älteren oder neueren Versionen von dem steht, was das Framework verwendet.

Answer 5

Das Problem bei jedem Wrapper ist die Entscheidung, wie Sie tatsächlich gewickelt werden und welche Funktionen Sie bieten:

• commons.logging ist eine minimale Menge von Logging-Funktionalität bereitstellt, zusätzliche Funktionen versteckt entfernt, dass der zugrundeliegende Rahmen könnte bieten. Sie erhalten keine erweiterten Funktionen wie parametrisierte Protokollierung oder MDC.
• SLF4J funktioniert andersherum. Es verarbeitet erweiterte Funktionen wie die parametrisierte Protokollierung, indem es sie über Frameworks implementiert, die sie nicht nativ implementieren. Das ist der bessere Weg, IMHO.

Ich weiß nicht Ihre aktuelle Debug-Klasse, aber ich denke, es ist ziemlich einfach.

Sie werden wahrscheinlich nicht haben Funktionen wie

• die Lage der Logging-Nachricht, dh Name der Quelldatei + Zeilennummer
• unterschiedlichen Protokollebenen
• die Fähigkeit, das Niveau selektiv eingestellt von verschiedenen Loggern, dh Sie haben keinen Logger pro Klasse und können diesen Logger auf ein bestimmtes Interessensniveau einstellen, z INFO, WARN. Das ist ziemlich wichtig.

Wenn Ihre Debug-Klasse ziemlich einfach ist das ist eigentlich sehr schön für Sie :)

Es bedeutet, dass Sie wahrscheinlich in der Lage sind zu SLF4J zu wechseln, indem einem globalen Suche & Destr durchführen. .. err ... ersetzen. obwohl

Backups, ...;)

Siehe auch Should new projects use logback instead of log4j?, What’s Up with Logging in Java?, Which log4j facade to choose?, Find a way in the java logging frameworks scene. und Do you find java.util.logging sufficient?. (Spoiler: Sie sollten nicht java.util.logging verwenden, bitte schön)

Answer 6

Ich denke, die Motivation hinter dem Wunsch des Architekten die Hülle zu wickeln (das heißt SLF4J), ist Ihre Anwendung von SLF4J zu isolieren. Wenn Sie die SLF4J-API in Ihrer Anwendung aufrufen, entsteht eine Abhängigkeit von SLF4J. Es ist jedoch gleichermaßen legitim, das Isolationsprinzip wiederholt anwenden zu wollen, wie unten diskutiert wird. Es erinnert mich an Richard Dawkins 'Frage: Wenn Gott das Universum erschaffen hat, wer hat dann Gott geschaffen?

In der Tat könnten Sie auch das Isolationsprinzip auf den Wrapper anwenden, der SLF4J umschließt. Die Ursache der Isolation wäre schlecht gedient, wenn der SLF4J-Wrapper SLF4J irgendwie unterlegen wäre. Obwohl es möglich ist, ist es eher selten, dass ein Wrapper dem Original entspricht oder dieses übertrifft. SWT kann als ein bemerkenswertes Gegenbeispiel angeführt werden. SWT ist jedoch ein beträchtliches Projekt mit erheblichen Kosten. Genauer gesagt hängt ein SLF4J-Wrapper definitionsgemäß von SLF4J ab. Es muss die gleiche allgemeine API haben. Wenn in Zukunft eine neue und deutlich andere Protokollierungs-API zur Verfügung steht, wird Code, der den Wrapper verwendet, genauso schwierig auf die neue API zu migrieren sein wie Code, der SLF4J direkt verwendet. Daher ist es unwahrscheinlich, dass der Wrapper Ihren Code zukunftssicher macht, sondern ihn durch Hinzufügen einer zusätzlichen Indirektion schwerer macht.

Kurz gesagt, auch wenn Sie nichts Besseres zu tun hatten, sollten Sie Ihre Zeit mit SLF4J nicht verschwenden, da der Mehrwert Ihres Wrappers garantiert nahe Null liegt.

Das Thema wird auch in einem SLF4J FAQ entry angesprochen.