Logging mit JSR 47 oder log4j ?

[Wang]

Hallo,

wie haben die folgende Aufgabe bekommen:

Eliminieren Sie aus Ihrem “Siedler von Catan”-Programm sämtliche direkte Ausgaben auf System.out und System.err (also z.B. auch Aufrufe von printStackTrace() auf Exceptions) und ersetzen Sie sinnvolle Ausgaben durch ein flexibleres Logging.

Zum Debuggen kann es hilfreich sein, den Ablauf des Programmes mehr oder weniger detailliert zu protokollieren. Durch angepasste Logging-Klassen können Sie dabei die Detail-Schärfe Ihrer Protokolle genau steuern und auch definieren, wo die Informationen zu finden sind.

Es empfiehlt sich das Loggen in je eine Datei für Protokollmeldungen des normalen Spielablaufs einerseits und die Protokollierung auftretender Exceptions andererseits. Etwa bereits vorhandene log-Dateien sollten aber bei einem neuen Programmlauf nicht einfach überschrieben werden. Dies erreichen Sie beispielsweise durch die Verwendung temporärer Dateien (Hinweis: die Methoden createTempFile in der Klasse java.io.File können hilfreich sein). Alle auftretenden Exceptions, auch wenn sie anderweitig behandelt werden, sollen in der Fehler-Log-Datei protokolliert werden.

Funktionalitätseinschränkungen gegenüber den Spielregeln, nicht sinnvoll behandelte Exceptions und Programmabstürze sind nun nicht mehr akzeptabel, die Jagd nach kleineren Bugs wird nun aber erst recht eröffnet.

Präsentieren Sie Ihr Programm benutzerfreundlich (als plattformunabhängig ausführbares Jar-Archiv) auf der Gruppenwebseite. Dazu gehört auch eine Benutzerdokumentation (nicht zu verwechseln mit der Programmdokumentation, die Sie mit javadoc erstellt haben). Die Benutzerdokumentation soll einem Benutzer, der sich nicht für Ihren Quellcode interessiert, erklären, was er tun muss, um mit Ihrem Programm “Siedler von Catan” zu spielen, und wo auf seinem Dateisystem eventuelle Protokolldateien angelegt werden. Die Bedienung sollte aber dennoch intuitiv sein und den Benutzer durch die Bedienung von Client und Server führen. Idealerweise werden Client und Server von einer gemeinsamen Oberfläche aus gesteuert, auf der der Benutzer entscheiden kann, ob er ein neues Spiel anlegen (als Server) und (als Client) auch mitspielen oder einem bereits angelegten (nur als Client) beitreten will.

Das Thema Logging ist vollkommen neu für mich und nachdem ich mich im Internet informiert habe, weiß ich, dass es die beiden Möglichkeiten JSR 47 und log4j gibt.
Das fertige "Siedler von Catan"-Projekt (.jar-Datei) muss am Ende auf einem Rechner der Uni präsentiert werden und darauf läuft Linux. Eine .jar-Datei von log4j wird auf dem Uni-Rechner höchstwahrscheinlich nicht vorhanden sein und der Einfachheit halber wird es wohl sinnvoller sein, JSR 47 zu verwenden, da hierfür nichts weiter installiert werden muss (fest vorgeschriebene Präsentationszeit, da kommt es sicherlich schlecht, wenn man da erstmal irgendwelche Dinge installiert, was mit Pannen verbunden sein kann).

Allerdings ist diese Vermutung ziemlich vage und es wäre deshalb sehr nett, wenn jemand, der sich mit dem Logging gut auskennt, hier seine Meinung darüber schreiben würde, welche der beiden Möglichkeiten die sinnvollere ist.

Zu obiger Aufgabenstellung noch zwei kurze Fragen:
- Ich habe das Prinzip des Loggings so verstanden, dass man theoretisch jede Zeile loggen kann. Verlangt die Aufgabe tatsächlich nur, dort ein Logging einzufügen, wo etwas ausgegeben wird?
- Sind mit "Protokolldateien" die Logdateien gemeint, also auf dem System eines jeden Spielers wird eine separate und bzgl. des Inhalts unabhängige Logdatei erstellt?

Vielen Dank für Eure Hilfe und Mühe!

Gruß
Wang

 

[stareagle]

Moin,

ich versuche mal ein wenig Licht in Dunkel zu bringen...

Das Thema Logging ist vollkommen neu für mich und nachdem ich mich im Internet informiert habe, weiß ich, dass es die beiden Möglichkeiten JSR 47 und log4j gibt.

Da sind dir einige Möglichkeiten entgangen. Es gibt zusätzlich noch Frameworks, mit denen die verwendete Logging-API abstrahiert wird. Damit kann z.B. erreichen dass, wenn kein log4j vorhanden ist, die Java eigenen Logging-Funktionen verwendet werden. Zum einen wären das Apache Commons Logging, zum anderen die Simple Logging Facade for Java (slf4j). Ich würde letzteres bevorzugen. Gründe findest du zum Beispiel in den auf der slf4j in der Dokumentation verlinkten Vorträgen.

Auf der slf4j Seite wird außerdem ein Logging-Framework namens Logback erwähnt. Logback ist eine Art inoffizieller Nachfolger von log4j.

Vor allem slf4j solltest du dir ansehen, da die Verwendung von slf4j (oder Commons Logging) es dir ermöglicht das Logging-Framework auszutauschen, ohne den Code deines Programms zu verändern.

Das fertige "Siedler von Catan"-Projekt (.jar-Datei) muss am Ende auf einem Rechner der Uni präsentiert werden und darauf läuft Linux. Eine .jar-Datei von log4j wird auf dem Uni-Rechner höchstwahrscheinlich nicht vorhanden sein und der Einfachheit halber wird es wohl sinnvoller sein, JSR 47 zu verwenden, da hierfür nichts weiter installiert werden muss (fest vorgeschriebene Präsentationszeit, da kommt es sicherlich schlecht, wenn man da erstmal irgendwelche Dinge installiert, was mit Pannen verbunden sein kann).

Bei Java-Programmen sollten alle Bibliotheken, die von dem Programm benötigt werden, im JAR des Programms mitgeliefert werden. Wenn du z.B. slf4j verwendest, solltest du die slf4j.jar in dem JAR deines Programms mitliefern.

Nun weiß ich nicht, welches Buildsystem du verwendest, oder ob du bisher nur aus Eclipse oder Netbeans heraus arbeitest. In diesem Fall würde ich dir empfehlen, ein von der IDE unabhängiges Buildsystem, z.B. Ant oder Maven, zu verwenden. Ich persönlich bevorzuge Maven. Dort kannst du z.B. über den Befehl

mvn assembly:single

Zu obiger Aufgabenstellung noch zwei kurze Fragen:
- Ich habe das Prinzip des Loggings so verstanden, dass man theoretisch jede Zeile loggen kann. Verlangt die Aufgabe tatsächlich nur, dort ein Logging einzufügen, wo etwas ausgegeben wird?

Wo wie das verstehe solle alle Meldungen, die bisher über [c]System.out[/c] laufen jetzt über Logging laufen. Das dürfte in erster Linie Meldungen über Fehler, Warnungen etc. betreffen.

- Sind mit "Protokolldateien" die Logdateien gemeint, also auf dem System eines jeden Spielers wird eine separate und bzgl. des Inhalts unabhängige Logdatei erstellt?

So verstehen ich es. Wo diese Dateien dann liegen usw. wird in der Konfiguration des Logging-Frameworks festgelegt.

Beste Grüße

Stareagle

 

[Wang]

Moin,

Da sind dir einige Möglichkeiten entgangen. Es gibt zusätzlich noch Frameworks, mit denen die verwendete Logging-API abstrahiert wird. Damit kann z.B. erreichen dass, wenn kein log4j vorhanden ist, die Java eigenen Logging-Funktionen verwendet werden. Zum einen wären das Apache Commons Logging, zum anderen die Simple Logging Facade for Java (slf4j). Ich würde letzteres bevorzugen. Gründe findest du zum Beispiel in den auf der slf4j in der Dokumentation verlinkten Vorträgen.

Auf der slf4j Seite wird außerdem ein Logging-Framework namens Logback erwähnt. Logback ist eine Art inoffizieller Nachfolger von log4j.

Vor allem slf4j solltest du dir ansehen, da die Verwendung von slf4j (oder Commons Logging) es dir ermöglicht das Logging-Framework auszutauschen, ohne den Code deines Programms zu verändern.

in der Insel heißt es: "Versuche, mit dem Apache Commons Logging (Commons Logging - Overview) die Logging-Bibliothek von Sun und log4j unter einen Hut zu bringen, führen in der Praxis zu gewaltigen Problemen."
Ob sich das auch auf slf4j bezieht, weiß ich nicht... Vielleicht hätte ich erwähnen sollen, dass es dem Lehrstuhl nur darum geht, dass wir die Mindestanforderungen erfüllen und wenn man dem Glauben schenkt, dann sollte JSR 47 wohl genügen.

Bei Java-Programmen sollten alle Bibliotheken, die von dem Programm benötigt werden, im JAR des Programms mitgeliefert werden. Wenn du z.B. slf4j verwendest, solltest du die slf4j.jar in dem JAR deines Programms mitliefern.

Nun weiß ich nicht, welches Buildsystem du verwendest, oder ob du bisher nur aus Eclipse oder Netbeans heraus arbeitest. In diesem Fall würde ich dir empfehlen, ein von der IDE unabhängiges Buildsystem, z.B. Ant oder Maven, zu verwenden. Ich persönlich bevorzuge Maven. Dort kannst du z.B. über den Befehl

mvn assembly:single

Bisher habe ich nur Eclipse (und mal kurz den JDeveloper) verwendet. Ich habe zwar im Internet versucht mich schlau zu machen, aber ich habe nicht verstanden, was der Unterschied zwischen IDE und einem Build-Management-Tool ist?

Ich verwende dann der Einfachheit halber die Logging-API von Java und wenn noch Zeit bleibt, "experimentiere" ich mit den anderen Technologien.
Zu log4j habe ich aber noch eine Frage: wenn ich dessen JAR-Datei in die JAR-Datei des Projektes packe, wie kann ich dann sicherstellen, dass dann auf dem Uni-Rechner beim Ausführen des Programms vom Projekt darauf auch zugegriffen wird?

Beste Grüße

Stareagle

Danke Dir!

Gruß
Wang

 

[stareagle]

in der Insel heißt es: "Versuche, mit dem Apache Commons Logging (Commons Logging - Overview) die Logging-Bibliothek von Sun und log4j unter einen Hut zu bringen, führen in der Praxis zu gewaltigen Problemen."
Ob sich das auch auf slf4j bezieht, weiß ich nicht... Vielleicht hätte ich erwähnen sollen, dass es dem Lehrstuhl nur darum geht, dass wir die Mindestanforderungen erfüllen und wenn man dem Glauben schenkt, dann sollte JSR 47 wohl genügen.

Unter anderem diese Probleme waren einer der Gründe für die Entwicklung von slf4j.

Bisher habe ich nur Eclipse (und mal kurz den JDeveloper) verwendet. Ich habe zwar im Internet versucht mich schlau zu machen, aber ich habe nicht verstanden, was der Unterschied zwischen IDE und einem Build-Management-Tool ist?

Eine IDE ist in der Regel eine GUI-Anwendung, die einen Editor mit Syntaxhervorhebung, Codevervollständig etc. bietet, sowie eine Projektverwaltung. Außer werden von einer IDE in der Regel verschiedene Tools unter einer halbwegs einheitlichen Oberfläche bereitgestellt. Ein Beispiel dafür ist z.B. der javac, den Eclipse z.B. beim Kompilieren aufruft. Eclipse bietet auch ein integiertes Build-Management, was aber nur in der IDE funktioniert. Spätestens wenn man mit mehreren Leuten an einem Projekt arbeitet, bekommt man damit Probleme... Wenn man z.B. mit GIT oder Subversion arbeitet, um die Sourcen zu verwalten, müsste man die Projektdateien von Eclipse miteinchecken, was keine gute Idee ist... Im Prinzip machen Build-Management Tools wie Maven oder Ant nichts anderes als die Schritte, die zum Erstellen eines lauffähigen Programms notwendig zusammenzufassen. Je komplexer solche Projekte werden, desto angenehmer werden solche Tools.

Daher verwendet man ein Build-Management-Tool. Beispiele im Java-Umfeld sind Ant und Maven (beides Projekte der Apache Foundation). Beispiele aus dem Umfeld von C/C++ sind Make und CMake.

Da diese Tools keine GUI benötigen, kann man sie z.B. auch auf einem Server ohne grafische Oberfläche ausführen, z.B. um Nightly Builds zu machen. Viele Projekte benutzen mittlerweile auch sogenannte Contineous Integration-Systeme, wie z.B. Jenkins. Diese sind insbesondere beim Entwickeln nach dem agilen Modell hilfreich. Das ganze läuft dann folgendermaßen (in groben Zügen): Zuerst Tests für gewünschtes Verhalten schreiben, dann implementieren. Sobald neuer Code eingecheckt wird, führt das CI-System einen Build aus, und lässt die Tests laufen. Das wiederholt man solange bis alle Tests durchlaufen.

Ich verwende dann der Einfachheit halber die Logging-API von Java und wenn noch Zeit bleibt, "experimentiere" ich mit den anderen Technologien.

Ich weiß nicht wie viel Zeit du noch bis zur Abgabe hast, aber das wird wahrscheinlich das einfachste sein.

Zu log4j habe ich aber noch eine Frage: wenn ich dessen JAR-Datei in die JAR-Datei des Projektes packe, wie kann ich dann sicherstellen, dass dann auf dem Uni-Rechner beim Ausführen des Programms vom Projekt darauf auch zugegriffen wird?

Der Classpath muss entsprechend gesetzt sein, was durch die Manifest-Datei im JAR erfolgen sollte. Du kannst dir ja mal eine JAR-Datei von irgendeinem Programm anschauen. Da JARs nur ZIP-Archive mit einer bestimmten Struktur sind, kannst du dir den Inhalt eines JARs über ein Archivprogramm ohne Probleme ansehen.

Sorry für die vielen Randinformationen, aber meiner Erfahrung nach kommt so was bei den Uni-Kursen immer zu kurz. Das Problem ist aber auch dass es einfach zu viel Dinge gibt, über man eigentlich Bescheid wissen müsste...

Beste Grüße

Stareagle

 

[Wang]

Eine IDE ist in der Regel eine GUI-Anwendung, die einen Editor mit Syntaxhervorhebung, Codevervollständig etc. bietet, sowie eine Projektverwaltung. Außer werden von einer IDE in der Regel verschiedene Tools unter einer halbwegs einheitlichen Oberfläche bereitgestellt. Ein Beispiel dafür ist z.B. der javac, den Eclipse z.B. beim Kompilieren aufruft. Eclipse bietet auch ein integiertes Build-Management, was aber nur in der IDE funktioniert. Spätestens wenn man mit mehreren Leuten an einem Projekt arbeitet, bekommt man damit Probleme... Wenn man z.B. mit GIT oder Subversion arbeitet, um die Sourcen zu verwalten, müsste man die Projektdateien von Eclipse miteinchecken, was keine gute Idee ist... Im Prinzip machen Build-Management Tools wie Maven oder Ant nichts anderes als die Schritte, die zum Erstellen eines lauffähigen Programms notwendig zusammenzufassen. Je komplexer solche Projekte werden, desto angenehmer werden solche Tools.

Das mit IDE ist mir inzwischen klar, aber mit dem Verstehen der Funktion eines Build-Management-Tools habe ich noch so meine Schwierigkeiten... Wir arbeiten auch mit Subversion und jeder verwendet Eclipse, auf ein Build-Management-Tool waren wir aber bisher nicht angewiesen (oder wir haben es zumindest nicht gemerkt). ???:L

Ich weiß nicht wie viel Zeit du noch bis zur Abgabe hast, aber das wird wahrscheinlich das einfachste sein.

Bis Donnerstag Vormittag. Auf den ersten Blick viel Zeit, aber wie ich inzwischen weiß, ist das Thema Logging so umfangreich, dass man dafür eine extra Vorlesung einführen könnte (wobei selbst dann der Großteil nicht behandelt werden könnte).

Der Classpath muss entsprechend gesetzt sein, was durch die Manifest-Datei im JAR erfolgen sollte. Du kannst dir ja mal eine JAR-Datei von irgendeinem Programm anschauen. Da JARs nur ZIP-Archive mit einer bestimmten Struktur sind, kannst du dir den Inhalt eines JARs über ein Archivprogramm ohne Probleme ansehen.

Okay, das mit dem Classpath geht ja dann bequem über Eclipse. Gibt es aber auch eine sinnvolle Möglichkeit, wenn man das manuell machen möchte?

Sorry für die vielen Randinformationen, aber meiner Erfahrung nach kommt so was bei den Uni-Kursen immer zu kurz. Das Problem ist aber auch dass es einfach zu viel Dinge gibt, über man eigentlich Bescheid wissen müsste...

Beste Grüße

Stareagle

Das große Problem an der Uni ist, dass es zuviele Vorlesungen über absolut irrelevante Themen gibt. Das beste Beispiel ist "Logik für Informatiker" - eine Vorlesung, die eine absolute Pseudowissenschaft darstellt. Der Professor wollte uns tatsächlich davon überzeugen, dass man mit irgendwelchen abstrusen Modellen der Vorlesung jeden einzelnen Fehler in jedem Quellcode finden kann und es angeblich viele Logiker gibt, die im Testing von Software Tausende von Euros verdienen.
Statt so eine bekloppte Vorlesung abzuhalten, wäre es um Lichtjahre sinnvoller gewesen, eine Vorlesung über das Debugging/Logging unter Verwendung gängiger Tools vorzusehen, denn dann hätte ich die Materie einerseits vermittelt bekommen und andererseits hätte ich mich bereits in die Thematik sukzessive und effizient eingelesen.
Natürlich kann an der Uni nicht jede Thematik abgedeckt werden, aber dann sollte man wenigstens keine unsinnige Thematik (Logik für Informatiker) behandeln.

Gruß
Wang

 

[stareagle]

Hallo nochmals,

Das mit IDE ist mir inzwischen klar, aber mit dem Verstehen der Funktion eines Build-Management-Tools habe ich noch so meine Schwierigkeiten... Wir arbeiten auch mit Subversion und jeder verwendet Eclipse, auf ein Build-Management-Tool waren wir aber bisher nicht angewiesen (oder wir haben es zumindest nicht gemerkt). ???:L

Ich gebe zu, die Sache ist ein wenig kompliziert. Möglicherweise hilft folgendes Buch (Kapitel 1):
Java Power Tools. Das Buch kannst du bei Kostenlos eBooks online lesen bei PaperC.de übrigens kostenlos lesen. Das Buch ist zwar schon etwas älter (2008), aber die in dem Buch beschriebenen Tools gibt eigentlich alle noch. Das Buch ist meiner Meinung nach eine Zusammenstellung von Tools für die Softwareentwicklung mit Java, die einem das Leben etwas einfacher machen können.

Bis Donnerstag Vormittag. Auf den ersten Blick viel Zeit, aber wie ich inzwischen weiß, ist das Thema Logging so umfangreich, dass man dafür eine extra Vorlesung einführen könnte (wobei selbst dann der Großteil nicht behandelt werden könnte).

Musst du mir nicht sagen War während meines Studiums nicht anders...

Okay, das mit dem Classpath geht ja dann bequem über Eclipse. Gibt es aber auch eine sinnvolle Möglichkeit, wenn man das manuell machen möchte?

Ich kenne leider Eclipse nicht so wirklich, aber dafür sollte Google was ausspucken. Wobei: Normalerweise sollte Eclipse das automatisch machen, wenn du eine Bibliothek als Abhängigkeit hinzufügst.

Das große Problem an der Uni ist, dass es zuviele Vorlesungen über absolut irrelevante Themen gibt. Das beste Beispiel ist "Logik für Informatiker" - eine Vorlesung, die eine absolute Pseudowissenschaft darstellt.

Ja, theoretische Informatik ist schon etwas esoterisch. Zum Glück mussten wir da nicht so viel machen... Aber die beiden Veranstaltungen im Grundstudium und die beiden im Hauptstudium haben mir gereicht. Das Problem ist auch dass das ganze viel Mathematik ist. Damit tun sich viele schwer.

Der Professor wollte uns tatsächlich davon überzeugen, dass man mit irgendwelchen abstrusen Modellen der Vorlesung jeden einzelnen Fehler in jedem Quellcode finden kann und es angeblich viele Logiker gibt, die im Testing von Software Tausende von Euros verdienen.

Es gibt schon Leute, die sich damit beschäftigen, wie man die Korrektheit von Programmen beweisen kann. Das ganze wird aber meistens nur in kleinen Teilbereichen gemacht. Zum anderen nutzen die Programme bei denen man das machen kann meist nicht den vollen Sprachumfang einer Sprache... Oder man nutzt funktionale Sprachen...

Statt so eine bekloppte Vorlesung abzuhalten, wäre es um Lichtjahre sinnvoller gewesen, eine Vorlesung über das Debugging/Logging unter Verwendung gängiger Tools vorzusehen, denn dann hätte ich die Materie einerseits vermittelt bekommen und andererseits hätte ich mich bereits in die Thematik sukzessive und effizient eingelesen.

Ich würde nicht unbedingt eine Vorlesung davon machen, aber du hast damit recht, dass es Veranstaltungen geben sollte, wo solche Dinge behandelt werden. Wobei das wahrscheinlich auch von Uni zu Uni verschieden ist. In Bremen zum Beispiel, wo ich studiert habe, hast du durch das in der Informatik immer noch hoch gehaltene Projektstudium für eine Uni recht viel Praxis.

Natürlich kann an der Uni nicht jede Thematik abgedeckt werden, aber dann sollte man wenigstens keine unsinnige Thematik (Logik für Informatiker) behandeln.

Ich glaube das kommt auch immer auf den Dozenten an. Der Professor in Bremen, der dort die Arbeitsgruppe Theoretische Informatik leitet, ist zum Beispiel sehr gut was das erklären seiner Sachen angeht. Und er hat ein sehr gutes Skript, das er zur Verfügung stellt. Bei den anderen Lehrveranstaltungen, die ich im Bereich theoretische Informatik gemacht habe, haben die Dozenten zumindest hin und wieder auch Beispiele gebracht, wo sie das ganze in konkreten Projekten einsetzen. Also ganz sinnlos ist das ganze nicht. Aber es kommt auch drauf an, welche Seite der Informatik einen interessiert.

Beste Grüße

Staragle

 

[Wang]

Danke für den Link zu dem Buch; sobald Semesterferien sind (ehrlich gesagt haben wir schon Semesterferien, aber das Softwarepraktikum läuft trotzdem bis zu ca. der Hälfte der Ferien weiter...) lese ich es mir durch, denn die zahllosen Technologien bereiten mir schon seit einiger Zeit ziemliche Kopfschmerzen...
Theoretische Informatik kann interessant sein, aber nur solange sie sich auf so Dinge wie den Hoare-Kalkül beschränkt.
Mein Ziel ist es, mich im Studium so weit wie möglich mit Java und all seinen Facetten vertraut zu machen, denn dann dürfte das Erlernen von Sprachen wie PHP, C++, ... einfacher sein und außerdem sollte das nach dem Studium hoffentlich die Jobsuche erleichtern.

Zum Thema:
Ich löse diese aufgabe mit der Java Logging API, habe aber noch drei Fragen:
- Laut Aufgabe dürfen bestehende Logdateien nicht überschrieben werden und hierfür sollen die Methoden createTempFile in der Klasse java.io.File hilfreich sein. Ich habe mir diese beiden Methoden in der API angesehen, sehe aber nicht, wie ich sie so verwenden kann, dass bestehende Dateien bestehen bleiben ???:L
- Kann man das Logging beim Starten der JAR-Datei des Projektes deaktivieren?
Falls ja, was wird dann stattdessen ausgegeben?
- In der Angabe heißt es ja "Es empfiehlt sich das Loggen in je eine Datei für Protokollmeldungen des normalen Spielablaufs einerseits und die Protokollierung auftretender Exceptions andererseits."
Soll ich hierfür zwei Logger schaffen oder gibt es da eine bessere Möglichkeit?

Vielen Dank!

Gruß
Wang

 

[stareagle]

Zum Thema:
Ich löse diese aufgabe mit der Java Logging API, habe aber noch drei Fragen:
- Laut Aufgabe dürfen bestehende Logdateien nicht überschrieben werden und hierfür sollen die Methoden createTempFile in der Klasse java.io.File hilfreich sein. Ich habe mir diese beiden Methoden in der API angesehen, sehe aber nicht, wie ich sie so verwenden kann, dass bestehende Dateien bestehen bleiben ???

Dieser Teil der Aufgabe kommt mir etwas seltsam vor. Üblicherweise überschreiben Logger eine vorhandene Log-Datei nicht, sondern hängen nur Daten an. Am besten probierst du das einfach mal aus.

- In der Angabe heißt es ja "Es empfiehlt sich das Loggen in je eine Datei für Protokollmeldungen des normalen Spielablaufs einerseits und die Protokollierung auftretender Exceptions andererseits."

Dafür müsste man wohl zwei Logger verwenden. Wie da genau bei java.util.logging funktioniert, kann ich dir auf Anhieb aber nicht sagen.

Beste Grüße

Stareagle

 

[Wang]

Dieser Teil der Aufgabe kommt mir etwas seltsam vor. Üblicherweise überschreiben Logger eine vorhandene Log-Datei nicht, sondern hängen nur Daten an. Am besten probierst du das einfach mal aus.

Ich habe hier einen Parallel-Thread laufen:

http://www.java-forum.org/java-basics-anfaenger-themen/113877-java-logging-api.html

Ich habe etwas mit dem dort verlinkten Programm experimentiert und die Logdateien werden leider überschrieben...

Dafür müsste man wohl zwei Logger verwenden. Wie da genau bei java.util.logging funktioniert, kann ich dir auf Anhieb aber nicht sagen.

Falls Du mal die Zeit/Motivation hast, wäre es sehr nett, wenn Du einen Blick in das Problem in meinem obigen Thread werfen könntest.

Danke Dir.

Gruß
Wang

 

[JohannisderKaeufer]

Deine Files werden überschrieben?

FileHandler (Java 2 Platform SE v1.4.2)

Verweist genau auf den Konstruktor des FileHandlers mit dem man das Anhängen an bestehende Logfiles einschalten kann, in dem man den Konstruktor zusätzlich mit true aufruft.
In einem propertiesfile könnte das so aussehen
java.util.logging.FileHandler.append = true

Bevor du aber in dem Sourcecode von deinem Projekt "rumpfuschst" würde ich dir empfehlen ein KSKB zu schreiben bei dem du ein oder zwei normale Ausgaben und eine Exception logst.
Dabei ist es auch leichter die Übersicht zu behalten.

Wenn du das dann postest, kann man dir bestimmt einen konkreten Hinweis geben, da die Fragen, dann auch im Kontext zu deinem Programm gesehen werden können.

Zu den Fragen im anderen Thread:
FileHandler (Java 2 Platform SE v1.4.2)
java.util.logging.FileHandler.level specifies the default level for the Handler (defaults to Level.ALL).

Bei der Configuration sollte man von folgender Reihenfolge ausgehen können( von unwichtig bis wichtig):
Der default Wert ist Level.All
Ist in der properties Datei ein Wert vorhanden, so gilt der Wert aus den properties und der default wird ignoriert.
Sollte im Programm ein explizierter Aufruf vorhanden sein, so gilt der explizite Aufruf und properties, sowie default Wert werden in Zukunft ignoriert(Bis zum nächsten Programmstart).

Zudem empfiehlt es sich den Logger mit folgender Zeile zu Initialisieren und seine gesamte Configuration in Propertiedatein vorzunehmen.

private final static Logger LOGGER = Logger.getLogger(this.class.getName());

Für das ändern von Logleveln, Handlern zur Laufzeit, gibt es Situation die das rechtfertigen. Das sollte aber nur in Ausnahmefällen geschehen.
z.B. Wenn ein Programm etwas nicht Ausführen möchte oder kann. Das man sich dann z.B. eine Fehlerkonsole einblendet, die andere Loglevel hat um dann sowas ähnliches machen zu können wie "Debuggen".
Diese Funktionen sind auch nötig, wenn man seine eigenen Logger bauen möchte.