Kann ein nicht statisches Protokoll gerechtfertigt sein?

8

Ich bin der einzige Maintainer in einer Codebasis, bei dem die Protokollierung mithilfe der Apache Commons-Protokollierung erfolgt.

Alle Klassen enthalten diese zwei Importe:

%Vor%

Dann enthalten viele Klassen eine nicht statische Protokollinstanz wie folgt:

%Vor%

Kann das gerechtfertigt sein?

Kann ich all dies sicher in statische Anrufe umwandeln?

BEARBEITEN In den speziellen Fällen, in denen es (scheinbar) nützlich sein kann: meine Frage ist wirklich mehr "Kann nicht statisches Protokoll über die Codebasis hinweg gerechtfertigt sein?"

    
Gugussee 27.01.2011, 14:22
quelle

4 Antworten

5

Sie müssen besonders vorsichtig sein, wenn nicht-statische Logger in Serializable classes initialisiert werden, wie das Code-Snippet funktioniert.

Erstens, weil Log nicht serialisierbar ist, so dass jeder Versuch, Ihre Klasse zu serialisieren, ebenfalls fehlschlägt. Wenn Sie Ihren Logger transient deklarieren, wird Ihr log -Feld nach der Deserialisierung nicht initialisiert, so dass Sie beim Versuch, Daten zu protokollieren, eine NPE erhalten. Nicht eine sehr schöne Situation.

Um es zusammenzufassen, können Sie also nicht-statische Logger verwenden, aber stellen Sie sicher, dass sie initialisiert sind, bevor Sie sie verwenden. Aber abgesehen davon würde ich mich nicht sehr um nicht-statische Logger kümmern, die meisten Logging-Implementierungen werden immer das gleiche Logger-Objekt zurückgeben (log4j tut das definitiv).

    
biziclop 27.01.2011, 14:44
quelle
8

Es kommt darauf an. Dies ist aus der Dokumentation :

  

Beachten Sie, dass es für Anwendungscode effizienter ist, das Protokollelement als "statisch" zu deklarieren, wenn pro Klasse ein Protokollobjekt erstellt wird, und wird empfohlen. Dies ist jedoch nicht sicher für eine Klasse, die über einen "gemeinsamen" Klassenlader in einem Servlet- oder j2ee-Container oder einer ähnlichen Umgebung bereitgestellt werden kann. Wenn die Klasse am Ende mit anderen Thread-Context-Classloader-Werten aufgerufen wird, darf das Member nicht als statisch deklariert werden. Die Verwendung von "statisch" sollte daher im Code innerhalb eines Projekts vom Typ "Bibliothek" vermieden werden.

    
berry120 27.01.2011 14:32
quelle
2

Eine Instanz, bei der es sich um einen nicht statischen Logger handelt, ist eine Art von Basisklasse, die den untergeordneten Klassen (zur Vereinfachung) eine Log-Instanz zur Verfügung stellt. Betrachten Sie das folgende Beispiel:

%Vor%

In diesem Beispiel erfolgt die Protokollierung von der Protokollinstanz "Cat". Ist dies eine gültige Begründung für die Verwendung eines statischen Loggers? Möglicherweise nicht für Nachrichten, die von der Cat-Klasse protokolliert wurden, aber Nachrichten, die von der Pet-Klasse unter der Cat-Protokollinstanz protokolliert wurden, könnten hilfreich sein.

    
jt. 27.01.2011 15:19
quelle
0

Hier ist ein Artikel, der das Gegenteil impliziert. In komplexen Situationen können Probleme beim Laden von Klassen bei statischen Protokollierern in Bibliotheken auftreten. Also ja, nicht-statische Logger können gerechtfertigt werden.

  

Betrachte jedoch den Fall, wenn eine Klasse "private static Log log =   ... "wird über einen ClassLoader bereitgestellt, der in der Herkunft von mehreren ist   angeblich unabhängige "Anwendungen". In diesem Fall ist das Protokollelement   nur einmal initialisiert, weil es nur eine Kopie der Klasse gibt.   Diese Initialisierung (normalerweise) erfolgt beim ersten Versuch eines Codes   um diese Klasse zu instanziieren oder eine statische Methode aufzurufen. Wann   Initialisierung der Klasse auftritt, was sollte der Log-Member gesetzt werden   zu?

Ссылка

    
Mike Pone 26.01.2012 21:33
quelle

Tags und Links