Best Practice zum Löschen von Log-Files?

[Daniel_L]

Hallo,

für meine Programme verwende ich einen Logger (diesen Standard-Logger, den NetBeans erzeugt, wenn man ein try/catch-Statement erzeugt). Dazu gibt es einen FileHandler, damit die Ereignisse auch gespeichert werden:

    public final static Logger zknlogger = Logger.getLogger(ZettelkastenView.class.getName()); 

        // init logger 
        FileHandler fh; 
        try { 
            fh = new FileHandler(System.getProperty("user.home") 
                   +java.io.File.separatorChar+".Zettelkasten" 
                   +java.io.File.separatorChar+"zknerror.log", true); 
            CConstants.zknlogger.addHandler(fh); 
            CConstants.zknlogger.setLevel(Level.ALL); 
            SimpleFormatter formatter = new SimpleFormatter(); 
            fh.setFormatter(formatter); 
        } 
        catch (IOException ex) {ex.printStackTrace();} 
        catch (SecurityException ex) {ex.printStackTrace();}

Der loggt auch wunderbar. Meine Frage ist: Werden die Log-Files irgendwann automatisch geleert? Da kann sich ja unter Umständen ganz schön was ansammeln, wenn man - wie ich in meinem Programm - auch andere Infos bei Bedarf mitloggt.

Oder was wäre die eleganteste/übliche Methode, das log-File "zurückzusetzen" bzw. zu leeren?

 

[Ebenius]

Das kann man einstellen; zum Beispiel in den logging.properties (siehe "java.util.logging.FileHandler.limit" und "java.util.logging.FileHandler.count"). Ein Beispiel gibt's [post=491612]hier[/post]. Die logging.properties kann man entweder systemweit setzen oder beim Programmstart mitgeben: Details verrät dazu die :rtfm: API-Doc der LogManager-Klasse.

Ebenius

 

[Daniel_L]

Danke, das schau ich mir mal an!

 

[Daniel_L]

So ganz versteh ich nicht, an welcher Stelle man wie die selbstgeschriebene Properties-Datei einbinden kann? Speicher ich die bspw. (unter NetBeans) im Resource-Verzeichnis, so dass sie beim Kompilieren mit in die Jar-Datei kann? Oder muss ich die properties-Datei als Parameter an die main()-Klasse übergeben?

Mir würde schon so etwas reichen wie "lösche bei jedem Programmstart erst mal die Log-Datei" oder so.

So wie ich das verstehe in der SUN-Dokumentation zum LogManager, wäre die eleganteste Methode, es über die Preference-Api zu setzen: These two properties may be set via the Preferences API, oder?

 

[Ebenius]

Wenn Du die Properties per "java.util.logging.config.file" angibst, muss die Datei vom Dateisystem (nicht aus einem JAR) lesbar sein. Wenn Du die Datei so nicht verfügbar machen kannst/willst, sondern aus dem Classpath (einem JAR), von einer Webseite, etc. lesen willst, brauchst Du eine Config-Klasse die per "java.util.logging.config.class" registriert wird und im einfachsten Fall so aussehen kann: [HIGHLIGHT="Java"]public class LoggingConfigurerer {
// must have a visible default constructor
public LoggingConfigurer() {
try {
final ClassLoader cl = LoggingConfigurer.class.getClassLoader();
LogManager.getLogManager().readConfiguration(
cl.getResourceAsStream("logging.properties"));
} catch (Exception ex) {
throw new Error("Could not initialize Logging", ex);
}
}
}[/HIGHLIGHT]
Wie Du die Properties setzt ist egal; es soltle jedoch passieren, bevor der LogManager seine Konfiguration gelesen hat. Mit der Preferences-API hab ich leider bisher nicht gearbeitet, weil sich die Möglichkeit nie bot.

Beim Programmstart kannst Du die Config-Datei so angeben:

java <Liste Deiner VM Argumente> -Djava.util.logging.config.file=/path/to/logging.properties [Main-Klasse] [Programm-Argumente]

Die Config-Klasse kannst Du beim Programmstart so angeben:

java <Liste Deiner VM Argumente> -Djava.util.logging.config.class=mein.package.LogConfigurer [Main-Klasse] [Programm-Argumente]

Hinterher die Konfiguration neu zu laden ist schwierig, weil es leider einen Fehler gibt, wenn man LogManager.readConfiguration() nachträglich aufruft. Wenn man einen Logger namens "foo.bar", dieser Logger bereits initialisiert ist, aber kein Logger namens "foo" initialisiert ist, ignoriert LogManager.reset() (wird von readConfiguration() aufgerufen) diesen Logger. Bei Sun hatte ich damals keinen Bug-Report gefunden, aus Zeitdruck aber auch keinen abgegeben; aus meinen Quelldateien mit Workaround (leider IP der Firma in der ich arbeite) geht hervor, dass dieses Problem seit Einführung der LogManager-Klasse in JRE 1.4 bis mindestens JRE 1.5.0_07 bestand.

Ebenius

 

[Daniel_L]

Es gibt ja - für meine bescheidenen Zwecke - eine ganz einfache Lösung, habe ich herausgefunden. Und zwar einfach ein anderer Konstruktor des FileHandlers:
FileHandler

Man kann dort bereits angeben, wie viel LogFiles man möchte und welche Größe die jeweils haben sollen, und mit appendMode = false schreibt er das log-File auch für jede Session neu.

 

[Ebenius]

Es gibt ja - für meine bescheidenen Zwecke - eine ganz einfache Lösung, habe ich herausgefunden. Und zwar einfach ein anderer Konstruktor des FileHandlers:
FileHandler

Man kann dort bereits angeben, wie viel LogFiles man möchte und welche Größe die jeweils haben sollen, und mit appendMode = false schreibt er das log-File auch für jede Session neu.

Das stimmt. Der FileHandler kann das schon alles, wie ich schon oben geschrieben habe. Die Frage ist ja nur, wie man die Konfiguration so macht, dass der FileHandler richtig an die Logger gepappt wird.

Ebenius

 

[Daniel_L]

Das stimmt. Der FileHandler kann das schon alles, wie ich schon oben geschrieben habe.

Das hast du aber ziemlich versteckt geschrieben - zumindest für mein Verständnis. ;-) Aber vielen Dank für die Hilfe!

 

[Ebenius]

Das hast du aber ziemlich versteckt geschrieben - zumindest für mein Verständnis.

Echt? Siehe:

Das kann man einstellen; zum Beispiel in den logging.properties [...]

Wesentlich deutlicher konnte ich nicht schreiben, dass man etwas einstellen kann.

Happy Hacking!
Ebenius