Johannes Schnatterer TRIOLOGY GmbH

Wer die aus Java gewohnten Logging-Funktionalitäten und seine Erfahrungen auch unter Android einsetzen möchte und nicht am DEX-Methodenlimit kratzt, dem ist logback-android zu empfehlen.

Wenn man als Java-Entwickler in die Android-Entwicklung einsteigt, ist zunächst vieles aus Java bekannt. Einige Aspekte sind aber auch anders gelöst, beispielsweise das Thema Logging. Hier bringt Android sein eigenes API mit, das ohne weitere Konfiguration bequem verwendet werden kann. Bei fortgeschrittenen Problemen hat dieser Ansatz jedoch seine Grenzen. Hier können Entwickler auf vorhandenes Wissen und Bibliotheken aus der Java-Welt zurückgreifen.

Für Neulinge erfreulich, lassen sich in Android ohne weitere Konfiguration die statischen Methoden der Klasse android.util.Log aufrufen, was zu einem Eintrag im systemweiten Log führt. Dieses kann mittels der Anwendung Logcat über den Android-Debug-Server (DDMS) oder direkt über eine Android Debug Bridge Shell (ADB) eingesehen werden. Während android.util.Log grundlegende Logging-Funktionalität bequem bereitstellt, bietet es keine Lösungen für fortgeschrittene Probleme wie Konfiguration, Integration der Logs von Bibliotheken oder Zugriff auf Logs aus der Anwendung. Viele Java-Entwickler würden solche Herausforderungen mittels SLF4J und Logback meistern.

Gerade durch sein einfaches API und die Möglichkeit der einheitlichen Konfiguration aller Log-Statements, auch von Third-Party-Code, hat sich die Simple Logging Facade for Java (SLF4J) in Java zum De-facto-Standard-Logging-API entwickelt. SLF4J stellt ein schmales API bereit, gegen das man im Code Log-Statements absetzt. Zusätzlich existieren Bridges, um Log-Statements, die mit anderen Logging-Frameworks abgesetzt wurden, auf SLF4J umzuleiten. Welches Logging Framework, also welche Implementierung, das SLF4J-API verwendet, muss erst beim Deployment entschieden werden.

Abbildung 1 zeigt die Schichten, Module und deren Zusammenhänge im Kontext von SLF4J. Die einzelnen Module stehen als separate JAR-Dateien zur Verfügung. Die Bezeichnungen der Schichten sind aus der SLF4J-Dokumentation übernommen. Vorsicht: Im Gegensatz dazu stehen die Bezeichnungen, die Log4J in der Version 2.0 seinen Modulen gibt: Das Bridging-Modul log4j-to-slf4j heißt Adapter und das Modul aus dem Adpation Layer log4j-slf4j-impl heißt Binding oder Bridge.

Abb. 1: SLF4J-Kontrollfluss, -Module und -Schichten

Unter anderem existieren Bridging-Module für Log4j 1.x (log4j-over-slf4j), Log4j 2.x (log4j-to-slf4j), Jakarta Commons Logging (jcl-over-slf4j) und Java Util Logging (jul-to-slf4j). Als eigentliche Implementierung des SLF4J-API stehen viele Logging-Frameworks zur Auswahl. Beispiele hierfür sind SLF4Js native Implementierungen Logback, dessen Fork logback-android, SLF4J Android, aber auch Adaptermodule für Log4j 1.x (slf4j-log4j12), Log4j 2.x (log4j-slf4j-impl), Java Util Logging (slf4j-jdk14) oder Jakarta Commons Logging (slf4j-jcl). Die Abstraktion über das SLF4J-API erlaubt es, das eigentliche Logging-Framework leicht auszutauschen, ohne den Code anzupassen.

Durch das Umleiten aller Log-Statements auf das einheitliche SLF4J-API ist es möglich, das Logging aller eingesetzten Bibliotheken durch das Framework der Wahl einheitlich zu konfigurieren. Denn die Konfiguration ist nicht Teil von SLF4J, sondern wird durch das Logging-Framework realisiert. Im Fall von Logback und logback-android ordnet man den im Code definierten Loggern Datensenken zu, so genannte Appender, beispielsweise Dateien, Standard Out oder das systemweite Android-Log. Die Formatierung der Log-Statements erfolgt innerhalb der Appender. Eine Filterung, welche Log-Level ausgegeben werden, lässt sich pro Appender oder im Code definierte Logger vornehmen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 9.17 - "Java EE 8"

Alle Infos zum Heft
579807479Android Logging für Java-Profis
X
- Gib Deinen Standort ein -
- or -