Log4j in jeder Klasse definieren?

[Tom299]

Hi,

ich hab in meinem Projekt Log4j testweise eingebaut (in 2 Klassen). Dabei mußte ich in beiden Klassen den Logger jeweils definieren:

private static final Logger logger = Logger.getLogger(Start.class);

Wenn ich jetzt 50 Klassen und mehr habe, die loggen sollen, muß ich da wirklich in jeder Klasse den Logger separat definieren? Ist es nicht möglich, den Logger in einer zentralen Klassen public static zu machen?
Ich hab auch schon sowas versucht, das Problem bei mir ist dann, daß der Logger immer bei der Ausgabe die Klasse angibt, für die er definiert wurde (also z.B. hier die Klasse Start). Wenn ich aber in der Klasse Person den gleichen Logger benutze, steht in der Ausgabe dann aber z.B. Start:42 obwohl es Person:42 sein müßte.

Wie kann man das lösen?

 

[Maggot]

Du kannst das nur lösen indem du in jeder Klasse separat den Logger definierst. Ich arbeite in der Arbeit an Projekten mit mehreren 1000 Klassen und überall wo der Logger benötigt wird, ist er in der Klasse separat definiert.

 

[Tom299]

Danke für die Info

 

[InfectedBytes]

Grundsätzlich musst du den Logger für jede Klasse separat erstellen.
Wenn du deine Objekte jedoch von einer gemeinsamen Basisklasse erben lassen kannst, kannst du auch folgendes tun:

public abstract class Loggable {
	private static HashMap<Class<?>, Logger> logger = new HashMap<Class<?>, Logger>();

	public Loggable() {
		if (!logger.containsKey(this.getClass())) {
			logger.put(this.getClass(), Logger.getLogger(this.getClass()));
		}
	}

	protected Logger getLogger() {
		return logger.get(this.getClass());
	}
}

class MyClass extends Loggable {
	public void test() {
		getLogger(); // liefert einen logger für die Klasse MyClass
	}
}

Alle Objekte die nun von Loggable erben, haben automatisch zugriff auf einen Logger ihrer jeweiligen Klasse.
Ist zugegebener Maßen keine "schöne" Lösung, aber sie erspart einem viel Schreibarbeit.
Selbstverständlich sollte das nur fürs Debuggen genutzt werden, im finalen Produkt sollte das gar nicht auftauchen.

p.s.
Falls du Java 8 benutzt, kannst du das auch mit Interfaces und default implementierung lösen.

public interface Loggable {
	public static HashMap<Class<?>, Logger> logger = new HashMap<Class<?>, Logger>();

	public default Logger getLogger() {
		Logger log = logger.get(getClass());
		if (log == null) {
			log = Logger.getLogger(this.getClass());
			logger.put(getClass(), log);
		}
		return log;
	}
}

 

[Tom299]

Vielen Dank, da ich Java8 nutze hab ich das grad mal so übernommen und funktioniert wunderbar.

Frage: Warum sollte das nur im Debugging benutzt werden? Loggen ist doch für die Fehlersuche ein super Hilfsmittel

 

[Joose]

Frage: Warum sollte das nur im Debugging benutzt werden? Loggen ist doch für die Fehlersuche ein super Hilfsmittel

Da hast du recht. Logging sollte immer eingesetzt werden.
Aber natürlich solltest du in einer produktiven Software nicht alles loggen, sondern nur das notwendigste (LogLevel).

 

[InfectedBytes]

Hab mal nachgesehen wie Logger.getLogger implementiert ist.
Den Code von oben kann man noch weiter vereinfachen:

public interface Loggable {
	public default Logger getLogger() {
		return Logger.getLogger(getClass());
	}
	//Außerdem kann man selbstverständlich shortcuts einbauen
	public default void debug(Object msg) {
		getLogget().debug(msg);
	}
}

 

[Tom299]

Danke, genauso hab ich es gemacht und noch die restlichen 4 Methoden ergänzt (info, warn, error, fatal).

Ich muß mir aber nochmal das neue Interface von Java8 ansehen, dachte es gäbe nur 1 default-Methode im Interface, zumindest hatte ich mir Lambda-Tutorials angesehen und da hab ich irgend sowas noch im Kopf, vielleicht bring ich aber auch was durcheinander

 

[stg]

Falls CDI zur Verfügung steht könnte man auch einen eigenen Producer schreiben

public class LoggerProducer {  
    @Produces  public Logger produceLogger(InjectionPoint injectionPoint) {  
        return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName());  
    }
}

 

[KSG9|sebastian]

Logger in einer Map cachen? Das ist ja grässlich.
Von einer Klasse zu erben nur (!) um eine Zeile zu sparen..pfui.

Zudem bin ich der Meinung, dass ein Logger nicht mit getClass() geholt werden sollte. Bei der Logausgabe interessiert dich die relevante Klasse, Methode u.s.w. Wenn du eine Klassenhierarchie mit 10 Klassen hast und die oberste Klasse macht Logger.getLogger(getClass()) dann hast du keine Ahnung in welcher konkreten Klasse geloggt wird und du kannst dir in der Hierarchie die relevante Klasse suchen..oder es wird von einer anonymen inneren Klasse geloggt, dann gute Nacht...

 

[InfectedBytes]

getClass gibt dir die konkrete Klasse, nicht die allgemeine.

Und als kleine site info, Log4j cached die Logger selbst auch mit einer Map ;-)

 

[KSG9|sebastian]

getClass() liefert dir die Klasse von der dein Objekt ist.

Folgende Hierarchie: A extends B, B extends C, C extends D

Klasse D macht nun Logger l = Logger.getLogger(getClass()). Jetzt loggst du in A, B und C mit l.info(".."). Dann siehst du in der Logausgabe als "Verursacher" des Logstatements immer nur "D", weil dein Objekt vom Typ D ist. Ob die Logausgabe aber innerhalb der Klasse A, B oder C gemacht wurde weißt du nicht - und das ist nicht gut. Damit suchst du wild durch die ganze Klassenhierarchie.

Und ja, log4j cached die Logger. Das ist der eine Grund, warum man selbst nicht noch dasselbe machen soll.
Zudem cached Log4j intelligent, threadsafe u.s.w. und diesen Mechanismus hebelst du unter Umständen durch eigenes Caching aus.

Eigene Caches sind allermeistens Müll, vor allem wenn sie aus ner HashMap bestehen und keine gescheite Eviction Policy u.s.w. besitzen...

 

[InfectedBytes]

Stichwort dynamische Methodenbindung.
Probier es aus und du wirst sehen:

class A {
	Class<?> clazz;
	public A() {
		clazz = this.getClass();
	}
}

class B extends A {
	public B() {
		System.out.println(clazz.getName());//Ausgabe B und nicht A
	}
}

Den Cache hatte ich erst eingebaut, da ich nicht geprüft hatte ob Log4j selbst cached. Und außerdem war es nur einfacher Beispielcode, natürlich kümmert sich das Beispiel nicht darum.
Außerdem habe ich später ja noch geschrieben, dass das eigene Cachen nicht nötig ist.