© Excellent backgrounds/Shutterstock.com
Java Magazin
SLF4J und Logback in Android

Android Logging für Java-Profis


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 [1]. 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 [2]. 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 [3].

schnatterer_slf4j_1.tif_fmt1.jpgAbb. 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. Beisp...

Java Magazin
SLF4J und Logback in Android

Android Logging für Java-Profis

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.

Johannes Schnatterer


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 [1]. 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 [2]. 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 [3].

schnatterer_slf4j_1.tif_fmt1.jpgAbb. 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. Beisp...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang