JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile
X

Schon abgestimmt im Quickvote? Docker versus Rocket - wer hat Recht?

Mit Version 2 soll alles besser werden

Das Comeback des Jahres: Apache log4j 2.0

Christian Grobmeier

Wer hätte das gedacht? Nachdem log4j 1 seit Jahren nur noch vor sich hin dümpelt, macht seit einigen Monaten ein eher überraschendes Gerücht die Runde: log4j 2.0 wird kommen. Das Apache-Logging-Projekt hat vor Kurzem den Entwicklungs-Branch für log4j 2.0 in den Mainbranch geschoben.

Wenn etwas einmal im Mainbranch liegt, dann wird es ernst genommen. Zumindest von den Entwicklern. Doch auch einige User zeigen sich mittlerweile vom zweiten Teil der log4j-Saga beeindruckt. Apache log4j 2.0 hat im Prinzip alles, was man sich heute so wünschen kann. Ein Release rückt immer näher. Es ist Zeit, einen genaueren Blick darauf zu werfen. Aber zunächst ein wenig Geschichte. Das E.U.-Semper-Projekt begann 1996 ein eigenes Logging-API zu schreiben. Nach zahlreichen Verbesserungen wurde daraus Apache log4j und damit das bis dato erfolgreichste Java Logging API. Doch dann kam es zu technischen Differenzen, die nicht einfach beigelegt werden konnten. Ceki Gülcü, der log4j zu Apache brachte, begann seine Ideen in Logback und slf4j umzusetzen. Das log4j-Team versuchte eine Version 1.3 herauszubringen - doch dies war mit weniger Erfolg gekrönt. Seitdem stagnierte die Entwicklung, wenn man von gelegentlichen Bugfix-Releases einmal absieht. Bis zu dem Zeitpunkt, an dem Ralph Goers einen erste Entwurf für log4j 2.0 vorstellte. Und seitdem kontinuierlich daran arbeitete, bis jetzt langsam tatsächlich ein Release in Sicht rückt.

Was ist besser an Apache log4j 2.0?

Apache log4j 2.0 lernt nicht nur aus den Erfahrungen der 1er Linie. Auch der von der Firma QOS vorangetriebenen Logback-Implementierung hat man auf die Finger geschaut. Man lernt also aus den Schwächen der vorhandenen Frameworks: Beispielsweise verlieren log4j 1 und Logback Logging-Events, wenn das Logging-System neu konfiguriert wird. Dies ist mit log4j 2.0 nicht der Fall. Exceptions, die in den Appender-Klassen auftreten (Appender "hängen" das Logging-Event an die Ausgabe, also z. B. das Logfile), werden von Logback verschluckt - mit log4j 2.0 kann man diese Exceptions optional ausgeben lassen. Apache log4j 2.0 verfügt über ein einfaches Plug-in-System. Damit ist es sehr einfach möglich, eigene Erweiterungen zu schreiben. Außerdem sieht die Konfiguration bei Weitem einfacher aus, weil beispielsweise Klassennamen nicht mehr darin enthalten sind. Während log4j 1.x und Logback Strings als Layout zurückgeben, verwendet log4j 2.0 Byte Arrays. Damit erhält man eine höhere Flexibilität wenn es um die Auswahl der Appender geht, denn es können jetzt auch solche Appender verwendet werden, die nicht in einen Output-Stream schreiben. Außerdem verwendet log4j 2.0 die Concurrency-Klassen aus Java 5. Threads und Locking werden mit ihrer Hilfe auf einem möglichst niedrigen Level und damit atomar angewandt. Damit fixt das API bereits viele bekannte Deadlock-Szenarien aus der log4j 1.x Welt. Und natürlich handelt es sich bei log4j 2.0 um ein Produkt der Apache Software Foundation. Damit ist man unabhängig von kommerziellen Betreibern und als Entwickler kann man prinzipiell selbst Commit-Rechte für das log4j Repository erhalten. Neue Gesichter werden tatsächlich gerne gesehen, melden Sie sich bei Interesse einfach in der Mailingliste.

Umsteigen?

Für Einsteiger ist es natürlich leicht, ein neues Logging-Framework zu verwenden. Aber nur selten dürfte man die Freude haben, sich so frei bewegen zu können. Wie sieht es denn aus, wenn alte Projekte mit anderen Abhängigkeiten auf log4j 2.0 umsteigen möchten? Für log4j-1-Benutzer wird eine Bridge bereitgestellt. Damit können die alten Interfaces weiterverwendet werden, die Methodenaufrufe werden aber an das neue API geleitet. Auch Apache-Commons-Logging-Benutzer können aufatmen - und sogar slf4j-Benutzer. Sogar für die "Simple Logging Facade"-Schnittstelle gibt es eine Anbindung. Damit dürfte für fast alle Entwickler der Weg frei sein, log4j 2.0 ohne große Probleme zu adaptieren.

Hello World!

Mit Apache log4j 2.0 ist das Loggen genauso einfach, wie man es eben bereits kennt (Listing 1). Zunächst wird über den LogManager ein Logger-Objekt geholt. Existiert dieses nicht, wird es vom Framework erzeugt. Das Logger-Objekt speichern wir in einer privaten und statischen Variablen. In der anschließenden main-Methode wird geloggt: Hello, World. Und das war's auch schon.

Listing 1
public class HelloWorld {
   private static Logger logger = LogManager.getLogger("HelloWorld");
   public static void main(String[] args) {
      logger.info("Hello, World!");
   }
}

Das Logger-Objekt kann natürlich mehr: es unterstützt Trace, Debug, Info, Warn, Error und Fatal. Die genannte Reihenfolge beschreibt auch die Reihenfolge der Priorität. Der Log-Level "Fatal" beispielsweise kann nicht abgestellt werden, während die weniger wichtigen Events von "debug" problemlos gefiltert werden können. Neben den bekannten isDebugEnabled-Methoden fällt eine weitere Schönheit sofort auf. Anstelle von:

if(logger.isDebugEnabled())
   logger.info("Hello, " + user.getAnrede() + " " + user.getName());

schreibt man mit log4j 2.0:

logger.info("Hello, {} {} ", user.getAnrede(), user.getName());

Die Methodensignatur ermöglicht es, eine variable Anzahl von Argumenten zu übergeben. Im oberen Beispiel wird zweimal geprüft, ob der entsprechende Log-Level erreicht wurde. Einmal im isDebugEnabled und einmal in der info-Methode. Dies ist bisher notwendig, da man sich natürlich unnütze String-Verkettungen sparen wollte. Kurzlebige Objekte sind teuer, vor allem, wenn sie nicht wirklich notwendig sind. Mit log4j 2.0 wird dieser Log-Level-Test nur einmal durchgeführt. Die fehlenden Verkettungen machen außerdem das Lesen leichter und geben einem das Gefühl, dass man an der Businesslogik arbeitet, anstatt am Logging-Code.

 
Verwandte Themen: 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).