Logging in Java. Java Logging API & Jakarta Log4J. Seminararbeit von Philipp Kaufmann, 5Ie

Transkript

1 Logging in Java Java Logging API & Jakarta Log4J Seminararbeit von Philipp Kaufmann, 5Ie Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: Prof. Dr. D. Gruntz Windisch, 16. Dezember 2002

2 Logging in Java: Java Loggin API & Jakarta Log4j Seite 1 Summary Logging in software applications goes far beyond the simple use of System.out.println instructions and helps software developers and supporters debugging, maintaining and servicing software. In Java, Jakarta s Log4j project and, since Java 1.4.0, Java Logging API offer solutions to realise structured logging of your application. Vorwort Der folgende Seminarbericht zum Thema Logging soll anhand einiger Beispiele erklären, was Logging ist und wie man in Java mit den beiden Frameworks Java Logging API und Log4j Loggersysteme nutzen kann. Der Bericht soll eine Einführung in das Thema sein und ist desshalb sicherlich nicht eine vollständige Beschreibung sämtlicher von den beiden Frameworks zur Verfügung gestellten Möglichkeiten. Wer genaueres über die Möglichkeiten von Java Logging API und Log4j wissen möchte verweise ich auf die Bibliographie im Anhang. Es ist jedoch zu bemerken, dass das Studium der Lektüre alleine keine tiefen Einblicke ermöglicht und man mit probieren und tüfteln eher in die Tiefen des Loggings eindringen kann.

3 Logging in Java: Java Loggin API & Jakarta Log4j Seite 2 Inhaltsverzeichnis 1 Was ist Logging Java Logging API Framework Funktionsweise Logger Log Levels Filter Handler Formatter Konfiguration Beispiele Jakarta Log4j Framework Funktionsweise Logger Log Levels Filter Appender Layout Konfiguration Das Chainsaw Tool Beispiele Fazit A. Bibliographie... 20

4 Logging in Java: Java Loggin API & Jakarta Log4j Seite 3 1 Was ist Logging Unter Logging versteht man die Ausgabe und das Festhalten von während der Laufzeit eines Programmes entstehenden Meldungen. Jeder Javaprogrammierer kennt den System.out.println() Befehl und nützt diesen um bestimmte Ausgaben auf der Konsole auszugeben, oftmals auch um Fehler zu lokalisieren. Logging geht weit über diese Funktion hinaus und ermöglicht dem Programmierer Debugmeldungen, Fehler oder andere Meldungen nicht nur auf der Konsole auszugeben, sondern diese auch in Dateien zu schreiben, über Netzwerkverbindungen zu senden oder anderweitig auszugeben und zu verwalten. Loggersysteme sollen aber nicht nur dem Entwickler das Programmieren und Debuggen erleichtern, sondern die Software auch besser wartbar und überwachbar machen, indem Informationen wie Ressourcenausnützung, Systemcrashes oder auftretende Fehler gespeichert werden und vom Software Supporter ausgewertet werden können. Loggersysteme wie Java Logging API oder Jakarta Log4j basieren auf dem Grundgedanken Meldungen verschiedener Softwarekomponenten unterschiedlich festhalten und behandeln zu können, so dass nur dann eine Information gespeichert oder ausgegeben wird, wenn das erwünscht ist. Um das zu ermöglichen bestehen beide Systeme aus drei Hauptkomponenten: Dem Loggerobjekt, welches einer Softwarekomponente zugeordnet wird und die eigentlichen Loggerfunktionen übernimmt. Einem Überwacher, der festlegt wann und wo etwas geloggt wird. Und dem Layout oder Format, das bestimmt wie die Informationen dargestellt werden sollen. In den folgenden zwei Kapiteln wird näher auf die beiden Loggersysteme Java Logging API und Log4j eingegangen.

5 Logging in Java: Java Loggin API & Jakarta Log4j Seite 4 2 Java Logging API Seit der Version 1.4 besitzt Java ein eigenes Logging API welches im package java.util.logging zu finden ist. Da dieses API noch relativ neu ist, wird es wahrscheinlich in nächster Zeit noch weiterentwickelt werden. In diesem Kapitel soll ein Überblick über das Framework und die Funktionsweise der einzelnen Klassen und Interfaces gegeben und anhand eines Beispiels erläutert werden. Der Inhalt dieses Kapitels stützt sich hauptsächlich auf die Java Dokumentation und die Java Logging Overview von Sun. 2.1 Framework Hier eine kurze Übersicht über das Java Logging API mit allen Klassen. Wie dieses API funktioniert wird in Kapitel 2.2 genauer erklärt. Interfaces Filter Classes ConsoleHandler ErrorManager FileHandler Formatter Handler Level Logger LoggingPermission LogManager LogRecord MemoryHandler SimpleFormatter SocketHandler StreamHandler XMLFormatter 2.2 Funktionsweise Wie oben gesehen besteht das Java Logging API unter anderem aus den Klassen Logger, LogRecord, Handler, Level, Filter und Formatter. Die Applikation, in welcher wir etwas loggen wollen, macht ihre logging Aufrufe auf Logger Objekten. Diese Logger senden ihrerseits einen LogRecord an einen Handler der dafür verantwortlich ist, wie die Meldung ausgegeben wird. Level und Filter werden dazu verwendet, um die Priorität oder Wichtigkeit eines LogRecords zu bestimmen. Dies ist dann nützlich, wenn wir nur bestimmte Meldungen, zum Beispiel nur von einer Klasse A, verarbeiten wollen.

6 Logging in Java: Java Loggin API & Jakarta Log4j Seite 5 Wollen wir unseren LogRecord extern ablegen, so muss nach dem Handler noch ein Formatter eingeschaltet werden, bevor die Meldung an einen I/O Stream geht Logger Das Logger Objekt wird benutzt um Meldungen für eine bestimmte Applikation zu loggen. Die Logger sind hierarchisch geordnet und können mit einem beliebigen Namen versehen werden, es ist jedoch üblich sie nach dem Packet oder Klassennamen zu benennen. Neben mit Namen versehenen Loggern besteht jedoch auch die Möglichkeit einen anonymen Logger zu generieren, der nicht im gleichen namespace liegt. Beispiel für einen Logger der Klasse LogB im Packet aaa.bbb: static Logger logger = Logger.getLogger("aaa.bbb.LogB"); Die Methode Logger.getLogger("aaa.bbb.LogB") gibt einen passenden Logger zurück falls schon einer existiert, andernfalls erstellt sie einen neuen Logger. Jeder Logger behält seinen nächsten Vorfahren oder Vater im namespace im Auge, im obigen Beispiel der Logger aaa.bbb, und erbt von ihm den Logging Level, Handler und Resource Bundle Name falls nichts anderes angegeben wurde. Der Vater eines anonymen Logger ist immer der root Logger mit dem Namen "". Die eigentlichen Logging Anfragen werden mit den Methoden log(), logp() und logrb() gemacht die sich nur geringfügig unterscheiden. Wenn aber nur ein einfacher String geloggt werden soll, können vereinfachte Methoden benutzt werden, die nach den jeweiligen Log Levels benannt sind. Beispiele für Logging Anfragen: // Standard log Aufruf: catch (Exception e) { logger.log(level.warning, "Hab eine Exception gefangen", e); // Vereinfachter Aufruf über entsprechenden Log Level: logger.info("das ist eine Info."); Bei den vereinfachten Loggern wie logger.info(string msg) wird unterschieden zwischen logging Methoden, die explizit einen Klassen- und Methodennamen verlangen, und diese dann auch genau so loggen, oder Methoden die nur eine Meldung, siehe oben, verlangen. Wird nur eine Meldung an die Methode übergeben, so wird das Logging Framework beim Loggen versuchen herauszufinden welche Klasse und Methode das Logging aufruft. Der Aufruf solcher Methoden ist zwar sehr simpel, erlaubt aber keine genauen Loggs. Beispiele für explizite und nicht explizite Angaben von Aufrufer Klasse und Methode:

7 Logging in Java: Java Loggin API & Jakarta Log4j Seite 6 logger.info(string sourceclass, String sourcemethod, String msg); logger.info(string msg) Log Levels Log Level dienen dazu, die Wichtigkeit und Dringlichkeit einer log Meldung zu bestimmen. Die Klasse Level enthält sieben, der Priorität nach geordnete, vordefinierte Levels: SEVERE (höchster Wert und somit höchste Priorität) WARNING INFO CONFIG FINE FINER FINEST (niedrigster Wert und niedrigste Priorität) Zusätzlich zu diesen Levels gibt es noch die Level OFF, um Logging auszuschalten, und ALL um jede Meldung zu loggen. Wird ein Logger mit einem bestimmten Level initialisiert, so werden alle Meldungen mit niedriger Priorität nicht berücksichtigt. Setzten wir also zum Beispiel unseren Logger logg mit dem Level WARNING werden nur Meldungen der Level WARNING und SEVERE geloggt. Beispiel für einen Logger logger mit Log Level WARNING: logger.setlevel(level.warning); Es steht dem Entwickler frei, neue Log Level zu definieren, jedoch muss darauf geachtet werden, dass der Prioritätswert (vom Typ int) einmalig ist und das Objekt Serializable bleibt Filter Zusätzlich zu den Log Levels können auch noch Filter eingebaut werden, um noch genauer zu unterscheiden was geloggt werden soll oder nicht. Filter werden mit der Methode setfilter(filter newfilter) einem Logger Objekt oder Handler (siehe Kapitel 2.2.4) zugeordnet um dessen Output zu kontrollieren. Im Interface Filter wird die Methode boolean isloggable(logrecord record) definiert. In der Implementation dieses Interfaces können Bedingungen angegeben werden, die bestimmen wann ein LogRecord geloggt werden soll. So können wir zum Beispiel bestimmen, dass nur Loggingnachrichten mit dem Level WAR- NING geloggt werden in dem wir die LogRecord Methode getlevel() aufrufen und den Rückgabewert in unserem Filter mit dem Level WARNING vergleichen. Auf diese Weise können in diesem Beispiel Meldungen mit dem Log Level SEVERE ausgefiltert werden.

8 Logging in Java: Java Loggin API & Jakarta Log4j Seite 7 Jeder Logger oder Handler ruft zuerst isloggable(logrecord record) auf und loggt ein Ereignis nur dann, wenn er als Rückgabewert true erhält Handler Jeder Logger verwaltet ein Set von Handlern, welche die Records an bestimmte Ziele schreibt/schickt. Default mässig schicken die Logger ihre LogRecords automatisch auch an den Vater-Logger. Logger können aber auch so konfiguriert werden, dass sie Handler die höher in der Hierarchie stehen ignorieren. Per Default besitzt Java folgende Handler: StreamHandler: Schreibt Log Record auf einen OutputStream. ConsoleHandler: Schreibt Log Record auf System.err (Konsole). FileHandler: Schreibt Log Record in eine Datei (siehe Bsp. Oben). SocketHandler: Sendet Log Record auf einen Socket. MemoryHandler: Puffert Log Records im Speicher. Es ist aber jederzeit möglich selber neue Handler zu entwickeln, in dem die Klasse Handler erweitert wird. Bemerkung: Die Level INFO und höher werden per Default auch auf die Konsole ausgegeben, FINER und niedriger nicht. Handlern kann, genau gleich wie bei Loggern, ein Log Level zugewiesen werden. Der Handler schreibt dann nur Meldungen mit gleichem oder höherem Wert an sein Ziel. Um ein Handler zu deaktivieren, wird im einfach der Level OFF zugewiesen. Es können auch mehrere Handler hintereinander geschaltet werden. Zum Beispiel kann ein MemoryHandler seine Records an einen FileHandler schicken. So können wir erreichen, dass die letzten zehn Meldungen vor einer Meldung des Log Levels SEVERE geloggt werden, in dem der MemoryHandler, der z.b. zehn Log Records speichert, seine Records beim Empfang einer severe Meldung an den FileHandler schickt Formatter Zusätzlich zu einem Filter kann ein Handler auch noch einen Formatter besitzen. Formatter stellen die Log Records in einem bestimmten Format dar. Java enthält von Werk her folgende beiden Formatter: SimpleFormatter: Er schreibt kurze, an uns Menschen angepasste Zusammenfassungen eines Log Records. XMLFormatter: Schreibt detaillierte XML Information.

9 Logging in Java: Java Loggin API & Jakarta Log4j Seite 8 Wie bei den Handlern können aber auch eigene Formatter entwickelt werden. Bemerkung: Mir ist aufgefallen, dass zum Beispiel der FileHandler default mässig einen XMLFormatter benutzt. Beispiele eines SimpleFormatter LogFiles (Beispiel für XMLFormatter siehe Kap. 2.3): :45:32 aaa.loga doa WARNUNG: Error in LogA! Konfiguration Da auch kleine Applikationen sehr bald sehr viele (tausende) Logger verwenden liegt es auf der Hand, dass es eine Möglichkeit geben muss, die Logger zu verwalten ohne jeden einzeln zu modifizieren. Alle Logger, Handler, Filter etc. können in einer Konfigurationsdatei im java.util.properties Format intitialisiert und über einen InputStream in den LogManager gelesen werden. Java Properties haben das Format key=value, wobei key als Variabelname und value als deren Wert in Form eines Strings angesehen werden können. Beispiel um den root Logger auf den Level SEVERE zu setzen: java.util.logging.rootlogger=severe Die Klasse LogManager stellt auch eine Methode readconfiguration() zur Verfügung, um config Files wieder zu lesen. Dabei werden alle bisher gemachten Veränderungen an Werten wieder auf die Werte im config-file zurückgesetzt. Durch Property-Files in Verbindung mit einem PropertyChangeListener im LogManager kann die Applikation zur Laufzeit rekonfiguriert werden. 2.3 Beispiele Ein einfaches Beispiel: package aaa; import java.io.ioexception; import java.util.logging.*; /** Phil Kaufmann */ public class LogA { static Logger logger; Handler fh; Formatter xml; public LogA() throws IOException{ logger = Logger.getLogger("LogA"); // wird automatisch zu aaa.loga

10 Logging in Java: Java Loggin API & Jakarta Log4j Seite 9 fh = new FileHandler("LogA.xml"); xml = new XMLFormatter(); fh.setformatter(xml); logger.addhandler(fh); public void doa() { double r = Math.random(); if(r<0.5){ logger.warning("error in LogA!"); else{ logger.info("loga ok :)"); package aaa.bbb; import java.io.ioexception; import java.util.logging.*; import aaa.loga; /** Phil Kaufmann */ public class LogB { static Logger logger = Logger.getLogger("LogB"); static Handler h; LogA a; public LogB(){ h = new ConsoleHandler(); h.setlevel(level.finest); logger.addhandler(h); logger.setuseparenthandlers(false); try{ a = new LogA(); logger.config("instanciated LogA."); catch (Exception e){ logger.severe("couldn't instanciate LogA!"); System.exit(1); public void dob() { logger.info("doing B."); a.doa(); package aaa.bbb.ccc; import java.io.ioexception; import java.util.logging.level; import java.util.logging.logger; import aaa.bbb.logb;

11 Logging in Java: Java Loggin API & Jakarta Log4j Seite 10 /** Phil Kaufmann */ public class LogC { static Logger logger = Logger.getLogger("LogC"); public static void main(string[] args) { logger.info("entering application"); LogB b = new LogB(); b.dob(); logger.log(level.info, "Exiting application"); Output auf Konsole: :42:31 aaa.bbb.ccc.logc main INFO: Entering application :42:34 aaa.bbb.logb dob INFO: Doing B :42:34 aaa.loga doa WARNUNG: Error in LogA! :42:35 aaa.bbb.ccc.logc main INFO: Exiting application Output in File LogA.txt: <?xml version="1.0" encoding="windows-1252" standalone="no"?> <!DOCTYPE log SYSTEM "logger.dtd"> <log> <record> <date> t20:53:38</date> <millis> </millis> <sequence>1</sequence> <logger>loga</logger> <level>warning</level> <class>aaa.loga</class> <method>doa</method> <thread>10</thread> <message>error in LogA!</message> </record> </log>

12 Logging in Java: Java Loggin API & Jakarta Log4j Seite 11 3 Jakarta Log4j Log4j ist ein open-source Projekt von Jakarta und eine sich ständig weiterentwickelnde Alternative zum Java Logging API von Sun. Log4j ist auch für die Sprachen C, C++ und C# erhältlich. In diesem Kapitel soll ein Überblick über das Framework und die Funktionsweise der einzelnen Klassen und Interfaces gegeben und anhand eines Beispiels erläutert werden. Der Inhalt dieses Kapitels stützt sich hauptsächlich auf das Log4j Manual von Ceki Gülcü und die Log4j Javadoc. 3.1 Framework Jakarta log4j enthält folgende Packages: org.apache.log4j org.apache.log4j.chainsaw org.apache.log4j.config org.apache.log4j.helpers org.apache.log4j.jdbc org.apache.log4j.jmx org.apache.log4j.lf5 org.apache.log4j.net org.apache.log4j.nt org.apache.log4j.or org.apache.log4j.or.jms org.apache.log4j.or.sax org.apache.log4j.performance org.apache.log4j.spi org.apache.log4j.varia org.apache.log4j.xml org.apache.log4j.xml.examples Wir beschränken uns jedoch auf das Haupt-Package org.apache.log4j mit folgenden Intefaces und Klassen: Interfaces Appender Classes AppenderSkeleton AsyncAppender BasicConfigurator Category ConsoleAppender DailyRollingFileAppender FileAppender Hierarchy HTMLLayout

13 Logging in Java: Java Loggin API & Jakarta Log4j Seite 12 Layout Level Logger LogManager MDC NDC PatternLayout Priority PropertyConfigurator RollingFileAppender SimpleLayout TTCCLayout WriterAppender Bemerkung: Die Klasse Category ist deprecated und wurde durch die Klasse Logger ersetzt. Um abwärtskompatibel zu bleiben wir die Klasse Category voraussichtlich bis Mitte 2003 weiterhin im log4j package vorhanden sein. 3.2 Funktionsweise Log4j funktioniert ähnlich wie das Java Logging API und besteht haupsächlich aus den Klassen Logger, Level und Layout und dem Interface Appender. Ich werde daher hauptsächlich auf die Unterschiede zwischen dem Java Logging API und Log4j eingehen und nur wo nötig zusätzliche Erläuterungen einbringen. Wer mehr Details möchte ist mit dem gut verständlichen Log4j Manual von Ceki Gülcü gut bedient. Um Log4j nutzen zu können, muss das Package org.apache.log4j eingebunden werden, in dem man den classpath auf das log4j.jar File setzt Logger Log4j Logger werden gleich wie Java Logging API Logger verwendet. Auch hier sind die Logger hierarchisch geordnet und vorzugsweise nach dem voll qualifizierten Klassennamen benannt. Am Anfang jeder Logger Hierarchie steht, wie bei Java Logging API, der root Logger. Logging Anfragen werden mit den Printmethoden debug, info, warn, error, fatal und log einer Logger Instance gemacht. Auch in Log4j erben die Logger den Level und die Appenders ihrer Vorfahren. Mit der Methode setadditivity(boolean additive) kann aber das additive Flag auf false gesetzt werden, was bewirkt, dass die Kinder dieses Loggers seine Appenders nicht erben. Bemerkung: Der root Logger besitzt per Default den DEBUG Level Log Levels Log4j besitzt fünf vorgegebene Log Level plus die Level ALL und OFF. Log Level werden in Java Logging API und Log4j auf die gleiche Art benutzt. Die fünf Log Level von Log4j heissen: FATAL (höchste Priorität)

14 Logging in Java: Java Loggin API & Jakarta Log4j Seite 13 ERROR WARN INFO DEBUG (niedrigste Priorität) Filter Die abstrakte Filter Klasse befindet sich im Package org.apache.log4j.spi und sollte vom Benutzer zuerst erweitert werden. Es ist in Log4j möglich, mehrere Filter hintereinander zu hängen und so eine Filterkette zu bauen die sequentiell durchlaufen wird beim Aufruf der Methode int decide(loggingevent event). decide gibt einen Wert zurück der einer der Konstanten DENY, NEUTRAL und ACCEPT entsprechen muss. Wird DENY zurückgegeben, so wird der Log Event verworfen und kein anderer Filter mehr aufgerugen. Bei der Rückgabe von NEUT- RAL wird der nächste Filter in der Kette aufgerufen. Ist kein Filter mehr übrig, wird der Log E- vent geloggt. Die Rückgabe von ACCEPT bewirkt das sofortige loggen ohne Konsultation der restlichen Filter Appender Appender übernehmen in Log4j die Funktionen, die bei Java Logging API die Handler haben. Appender bezeichnen das Ziel, an welches der Log Request geschickt oder geschrieben werden. Es existieren bereits folgende Appender im log4j Package: ConsoleAppender: Schreibt Log Events auf Seytem.out oder System.err(Default). FileAppender: Schreibt Log Events in eine Datei. RollingFileAppender: Erweiterung von FileAppender um Logfiels zu sichern, wenn sie eine bestimmte grösse erreicht haben. DailyRollingFileAppender: Erweiterung von FileAppender um Logfiles in bestimmten Zeitabständen zu sichern (z.b. täglich, wöchentlich, ). WriterAppender: Vaterklasse von ConsoleAppender und FileAppender. Loggt Events entweder auf einem Writer oder OutputStream. AsyncAppender: Ermöglich aynchrones Loggen und speichert alle Log Events in einem Puffer bevor er sie an einen oder mehrere Appender weitergibt (ähnlich MemoryHandler in Java Logging API). Bemerkung: In den Packages log4j.jdbc, log4j.net, log4j.nt, und log4j.varia befinden sich weiter Appender um auf externe Ziele wie Sockets zu loggen. Ich gehe hier aber nicht weiter auf diese Appender ein, da die oben genannten Appender uns zur Zeit genügen

15 Logging in Java: Java Loggin API & Jakarta Log4j Seite 14 sollten. Nähere Erklärungen zu allen Appendern sind der log4j Javadoc zu entnehmen. Alle Appender implementieren das Appender Interface und erweitern die abstrakte Klasse AppenderSkeleton. Es können somit jederzeit auch eigene Appender entwickelt werden. Es gelten für Log4j Appender dieselben Regeln wie für Java Logging Handler. Es können auch wieder mehrere Appender hintereinander geschachtelt werden. Jeder Appender sendet seinen Output an seine Vorfahren. Hat aber ein Vorfahre von Logger A, wir nenne ihn Logger B, sein additivity Flag auf false gesetzt, so wird der Output von A an alle Appender in A und in seinen Vorfahren bis und mit B gesendet, aber nicht in irgendein Vorfahre von B Layout Um zusätzlich zum Ausgabeziel auch das Ausgabeformat zu bestimmen wird dem Appender ein Layout zugewiesen (vgl Formatter). In Log4j sind folgende Layouts bereits enthalten (Package log4j falls nichts anderes angegeben): SimpleLayout: Besteht aus dem Log Level und der Log Message PatternLayout: Damit lässt sich ein Log Event beliebig formattieren. Die Bedienung ähnelt der, der printf - Funktion der Sprache C. HTMLLayout: Schreibt die Events in eine HTML Tabelle. TTCCLayout: Erweiterung des DateLayout. Stellt den Output in Form von Time, Thread, Category (bez. Logger) und Context Informationen dar. Dem Layout muss ein Zeit-Datum Format engegeben werden (per Default wird das RelativeTimeDateFormat aus dem Package org.apache.log4j.helpers verwendet). log4j.xml.xmllayout: Schreibt XML Informationen unter Verwendung der log4j.dtd. Beispiele: SimpleLayout: Aufruf: logger.debug("message 1"); Output: DEBUG - Message 1 PatternLayout: Erstellen des Layouts: layout.setconversionpattern("%-5p [%t]:%m%n"); Aufruf: logger.debug("message 1"); Output: DEBUG [main]: Message 1 TTCCLayout: Output (Default Konfiguration):

16 Logging in Java: Java Loggin API & Jakarta Log4j Seite [main] INFO org.apache.log4j.examples.sort - Exiting main method. Die erste Zahl (467) gibt dei Anzahl verstrichener Millisekunden seit Programmstart an Konfiguration Wie in Java Logging API kann auch in Log4j die Konfiguration über Java Property Files vorgenommen werden. Die Propertyfiles werden im Programm mit BasicConfigurator.configure("filename ") geladen. Ein Beispiel dazu ist in Kapitel 3.4 zu finden. 3.3 Das Chainsaw Tool Chainsaw ist eine graphische Oberfläche mit der Logging Events angeschaut und gefiltert werden können. Chainsaw horcht per Default nach LoggingEvents die einen SocketAppender verwenden und stellt diese in einer Tabelle dar. Mit dem SocketAppender können Logger Kontakt mit einem Remote Host aufnehmen. Weiteres zum SocketAppender findet man in der Javadoc unter dem Package org.apache.log4j.net. Es ist auch möglich, Events aus einer XML Datei zu laden, was den Vorteil hat, dass Chainsaw nicht immer Online sein muss. Um Logging Events an Chainsaw schicken zu können muss Log4j konfiguriert werden. Dies kann durch ein Property-File geschehen wie im folgenden Beispiel gezeigt.

17 Logging in Java: Java Loggin API & Jakarta Log4j Seite 16 log4j.rootlogger=debug, CHAINSAW_CLIENT log4j.appender.chainsaw_client=org.apache.log4j.net.socketappender log4j.appender.chainsaw_client.remotehost=localhost log4j.appender.chainsaw_client.port=4445 log4j.appender.chainsaw_client.locationinfo=true 3.4 Beispiele Zuerst ein einfaches Beispiel: package simple; import org.apache.log4j.*; /** Phil Kaufmann */ public class SimpleLog { Output: static Logger logger = Logger.getLogger("SimpleLog"); public static void main(string[] args) { BasicConfigurator.configure(); logger.info("simple :)"); 10 [main] INFO SimpleLog - Simple :) Hier ein zweites Beispiel mit einer Property Konfigurationsdatei: # Filename: l4jconfig.txt # Property configuration file for log4j # Properties of root Logger log4j.logger.rootlogger=debug, A log4j.appender.a=org.apache.log4j.consoleappender log4j.appender.a.layout=org.apache.log4j.simplelayout # (Bei Verwendung von Chainsaw folgende Konfiguration: # # Properties of root Logger # log4j.rootlogger=all, CHAINSAW_CLIENT # log4j.appender.chainsaw_client=org.apache.log4j.net.socketappender # log4j.appender.chainsaw_client.remotehost=localhost # log4j.appender.chainsaw_client.port=4445 # log4j.appender.chainsaw_client.locationinfo=true # ) # Properties of Logger LogA log4j.logger.aaa.loga=all, A11, A12 log4j.appender.a11=org.apache.log4j.fileappender log4j.appender.a11.file=erra.txt log4j.appender.a11.layout=org.apache.log4j.simplelayout log4j.appender.a12=org.apache.log4j.consoleappender log4j.appender.a12.layout=org.apache.log4j.simplelayout

18 Logging in Java: Java Loggin API & Jakarta Log4j Seite 17 # Properties of Logger LogB log4j.logger.aaa.bbb.logb=debug, A2 log4j.appender.a2=org.apache.log4j.consoleappender log4j.appender.a2.layout=org.apache.log4j.xml.xmllayout # Properties of Logger aaa.bbb.ccc.logc log4j.logger.aaa.bbb.ccc.logc=debug, A3 log4j.appender.a3=org.apache.log4j.consoleappender log4j.appender.a3.layout=org.apache.log4j.simplelayout package aaa; /** Phil Kaufmann */ import org.apache.log4j.logger; public class LogA { static Logger logger = Logger.getLogger(LogA.class); public void doa() { double r = Math.random(); if(r<0.5){ logger.error("error in LogA!"); else{ logger.info("loga ok :)"); package aaa.bbb; /** Phil Kaufmann */ import org.apache.log4j.*; import aaa.loga; public class LogB { static Logger logger = Logger.getLogger(LogB.class); LogA a = new LogA(); public void dob() { BasicConfigurator.configure(); logger.debug("doing B."); a.doa(); package aaa.bbb.ccc; /** Phil Kaufmann */

19 Logging in Java: Java Loggin API & Jakarta Log4j Seite 18 import org.apache.log4j.logger; import org.apache.log4j.propertyconfigurator; import aaa.bbb.logb; public class LogC { static Logger logger = Logger.getLogger(LogC.class); public static void main(string[] args) { PropertyConfigurator.configure("l4jconfig.txt"); logger.info("entering application"); LogB b = new LogB(); b.dob(); logger.info("exiting application"); Output Konsole: INFO - Entering application <log4j:event logger="aaa.bbb.logb" timestamp=" " level="debug" thread="main"> <log4j:message><![cdata[doing B.]]></log4j:message> </log4j:event> 40 [main] DEBUG aaa.bbb.logb - Doing B. ERROR - Error in LogA! 50 [main] ERROR aaa.loga - Error in LogA! INFO - Exiting application 50 [main] INFO aaa.bbb.ccc.logc - Exiting application Output in File erra.txt: ERROR - Error in LogA

20 Logging in Java: Java Loggin API & Jakarta Log4j Seite 19 4 Fazit Beide Tools sind sich sehr ähnlich und es ist desshalb sehr schwer zu sagen, welches jetzt besser sein soll. Das Java Logging API scheint mir schlanker und einfacher zu bedienen, jedoch dünkt mich die Dokumentation nicht besonders gut. Bei Log4j hat man ein mächtiges Tool, das für den Einstieg ins Logging auch ziemlich gut Dokumentiert und beschrieben ist. Jedoch empfand ich Log4j als Anfänger bedeutend schwieriger zu bedienen als dass ich es erwartet hatte. Dies liegt vermutlich an den unglaublich vielen Möglichkeiten, welche Log4j zu bieten hat und an den Altlasten und Leichen wie die Klasse Category, welche immer noch irgendwie benutzt werden. Im Grossen und Ganzen denke ich also, dass für Anfänger und Programmierer, die nur einen schnellen, simplen Logger brauchen die Lösung von Sun besser ist. Für komplexere Loggersysteme denke ich jedoch, dass Log4j noch die Nase vorn hat.

21 Logging in Java: Java Loggin API & Jakarta Log4j Seite 20 A. Bibliographie Java Logging API: Sun, Java Logging Overview, , Sun, Java 2 Platform SE v1.4.0 API Dokumentation, Jakarta Log4j: Ceki Gülcü, Short introduction to log4j, März 2002, Jakarta und diverse Authoren, Log4j Version Javadoc, jakarta-log4j-1.2.7\docs\api\index.html