Grösse von Logfiles

[trez]

Gibt es eine Möglichkeit die Grösse von Files zu begrenzen und zwar so, dass ab einer bestimmten Grösse immer die ältesten Zeilen rausfliegen wenn neue geschrieben werden? (Wenn das nicht genau zeilenorientiert funktioniert sondern eine Anzahl Bytes verwirft, ist es auch egal)

In meinem Projekt wird ein Logfile geschrieben. Das wird erstellt, dann der syserr darauf umgeleitet und das wars.

Kurzfassung:

public void init() {
...
FileOutputStream fos = new FileOutputStream(name, false);
PrintStream ps = new PrintStream(fos);
System.setErr(ps);
} // und weg sind ps und fos ...

Gibt es die oben genannte Möglichkeit auf für Files, die nicht umgeleitet und "vergessen" werden ohne dass man das selbst auscodiert?

Etwas was mich am angewendeten Verfahren überrascht ist die Tatsache, dass offensichtlich auch bei Abstürzen immer alles ins Log-File geschrieben wird, obwohl es da ja keinen sichtbaren flush oder close gibt und das muss zwingend so bleiben. Auch möchte ich nicht das ganze logfile irgendwie buffern und immer das Ganze schreiben

Ja java.util.logging.FileHandler habe ich kurz angeschaut (sehr kurz, ich gebs zu) aber XML möchte ich nicht in den Logfiles - das soll reiner Text bleiben, da sich diverse Kunden angewöhnt haben, das selbst zu lesen und das sind keine Softies
So nebenbei: Wenn ich jetzt überall System.err.println ersetzen muss, wird es sehr aufwendig und das spricht auch gegen java.util.logging.

 

[maki]

System.err ist keine echte Option für Logging, einerseits kann das sehr langsam werden da synchronisiert, anderseits hat man so gut wie keine Konfigurationsmöglichkeiten.

Würde dir also auf jedenfall zum Logging APIs raten, java.util.Logging ist dabei die am wenigsten gute, log4j ist zwar alt aber noch i.O., am besten gleich SLF4J & Logback nutzen, beide unterstützen deine Anforderungen.

 

[musiKk]

Du könntest Dir natürlich einen eigenen [c]OutputStream[/c] schreiben, der das macht. Ohne mir das jetzt sehr genau angeschaut zu haben, sollte der Aufwand sogar relativ gering sein. Du musst halt die [c]write[/c]s wrappen und mitzählen.

Das ist aber trotzdem gehackt. Ein Logging-Framework ist dringend zu empfehlen (log4j oder gleich slf4j).

 

[trez]

Obwohl eigentlich alles funktioniert, ist längst nicht alles was ich hier so geerbt habe auch gut :noe:
Ich scheue mich einfach noch davor die System.err.printeln suchen zu gehen - der Aufwand diese zu ersetzen ist kaum abschätzbar und sollte fliessend geschehen.

Ohne schon selbst gelesen zu haben - könnte ich in der Übergangsphase den Output eines der erwähnten Loggig-Freamsworks mit sem syserr.ouput zusammenfliessen lassen?

 

[maki]

System.err würde ich zuerst durch ein Interface ersetzen und dieses dann später durch richtige Logger, oer gleich durch richtige Logger, ist nciht wirklich wild, mit suchen & ersetzen kommt man da schon sehr weit

Problematisch ist eben, dass für Logging nur selten Unittests existieren und refactoring ohne tests ist immer ein Spiel mit dem Feuer.

 

[trez]

Räusper - das Handwerkliche ist das kleinste Problem - das Organisatorische eher - wer macht wann welche Units und Tests. Die ausgelasteten Leute hier haben ja nur einen halbwegs fähigen Chef als Verstärkung, der natürlich nebenei nichts anderes zu tun hätte

Nein, Spass beiseite es muss fliessend gehen. Anders kann das nicht bewältigt werden. Wenn eine Unit sowieso bearbeitet wird, kann etwas geändert werden - sonst nicht.

Das mit dem Interface habe ich überhaupt nicht verstanden, aber ich glaube das bringt auch nichts.

Da liegen mehrere 100 Units rum die den syserr benutzen und diese Woche wird eine davon geändert.
Der Output der geänderten muss am selben Ort landen wie der aller anderen.
Also muss der output des Logframeworks auf syserr umgeleitet sein, bis alles erledigt ist.

EDIT: Unsere Unittests werden nicht auf den output angewendet, das ist egal, wenn der Logger nicht testbar ist, aber jede veränderte Unit sollte (die Realität lässt grüssen) getestet werden.
Und sonst bastle ich dann einen LogMock - Mocks basteln ist mein Hobby, weil es so schön einfach ist ;-)

 

[maki]

Klar kann man das Log auf SysErr ausgeben lassen, aber... wenn man gar nicht wirklich vorhat zu richtig refactoren, sollte man es gleich bleiben lassen, sonst hat man zum Schluss eine Übergangslösung dir für immer bleibt und 2 Loggingmechanismen umfasst...

 

[trez]

Richtig refactoren - ja logisch, aber ich frage mich in was für Bonsaiprojekten du arbeitest ;-) mit den verfügbaren Resourcen würde das Refactoring wohl deutlich über einen Monat dauern, wenn wir es intensiv betreiben, aber das kann ich unmöglich machen. Daneben wird normal weiterentwickelt - also werden immer wieder mal Zwischenreleases erstellt die laufen müssen. Wir werden nicht ohne Mischvarianten über die Runden kommen.

Ich rechne damit, dass es 3 - 5 Monate dauert.

Richtiges Refactoring in einem mittleren oder grösseren Projekt geht IMHO niemals in einem Rutsch - das Tagesgeschäft für den Zeitraum stillzulegen kann sich wohl auch kaum jemand leisten und ausserdem ist das Risiko ist sehr gross (auch wenn man es richtig macht).

 

[bygones]

Richtiges Refactoring in einem mittleren oder grösseren Projekt geht IMHO niemals in einem Rutsch - das Tagesgeschäft für den Zeitraum stillzulegen kann sich wohl auch kaum jemand leisten und ausserdem ist das Risiko ist sehr gross (auch wenn man es richtig macht).

behauptet auch keiner dass ein Refactoring innerhalb eines Rutsches. Dennoch sind deine argumente die typischen weswegen man sich bestehende Probleme kuemmert bzw warum man sie dadurch immer wiederholt (nicht persoenlich, aber diese argumentation ist nun mal standard ;-))

Ausserdem wenn man zb richtig in einer IDE refactored uebernimmt diese die meiste arbeit. 100 Tests zu refactoren sollte in kurzer zeit machbar sein.

und warum muss ein refactoring das tagesgeschaeft lahmlegen ? dem sollte es egal sein wie geloggt wird, wenn nicht, dann ist das problem grundlegender

 

[maki]

Hehehe.. bonsai ist gut
Naja, zumindest sind sie selten so amateurhaft um System.err zu verwenden... sorry, aber das musste sein.

Tatsache:
Man kann auch 1000000 Zeilen Code durch Search & Replace "refactoren", dauert nur ein paar Stunden (replace all )
Das Problem ist da Risiko dabei.

"Richtiges Macro-Refactoring" bezieht sich eigentlich auch nie auf nur einen einzigen Aspekt wie logging, so gesehen ist System.err ersetzen "Kindergeburtstag", da wird auch nicht viel am Design geändert.

Da es sich beim System.err wohl nur um Fehlerlogging handelt (?) müsste ja ein logger.error(..) anstatt des System.err eingesetzt werden, gibt es da ein realistisches Risiko?

Was mir so ein bisschen komisch vorkommt sind eure regeln, kein refactoren ohne dass die "Unit" sowieso angefasst werden muss, sorry, das funktioniert nur bei Micro-refactoring, und jetzt soll alles per Tests geprüft werden, früher hat man noch nicht mal richtiges Logging verwendet?

Wie dem auch sei, das erste wäre wohl Unit- und Integrationstests für die jetzige Lösung zu schreiben, dann das refactoren, ist ja wohl trivial in diesem falle (zur Erinnerung, System.err -> logger.error, einen Import und die initialisierung des Loggers), k.A. was da 3-5 Monate dauern soll???

Warum sollte das "Tagesgeschäft" stillstehen??

 

[trez]

Hehehe.. bonsai ist gut
Naja, zumindest sind sie selten so amateurhaft um System.err zu verwenden... sorry, aber das musste sein.

Das durfte auch sein ;-) Unter meinen Fittichen wurde das auch nicht kreiiert, weobei es sogar möglcih wäre dass es damals weder log4j noch slf4j gegeben hat ...
Aber ich frage mich schon wer die Weiterentwicklung anhalten kann, nur um in allen Modulen gleichzeitig etwas zu ändern was nicht gleichzeitig geschehen müsste - ist mir in 20 Jahren noch nicht vorgekommen.
(Ausserdem war/ist logging immer eher eine Stiefkind

slf4j-simple:
Geht auf syserr, kann später ersetzt werden, aber was bringt mir das eigentlich? Bis jetzt habe ich nichts spektakuläres entdeckt. Nur um Zeitstemple und eine BEzechung zu ergänzen brauche ich kein Framework.
Warum gibt es eine SimpleFactory? Sehr unegschickt die zu verwenden, denn die müsste ja später durch die Factory ersetzt werden.

log4j:
Muss ich erst mal anschauen, aber wenn ich das nicht auf syserr umleiten kann und das noch weniger bietet ist das refactoringprojekt gestorben bevor es geboren wurde. Oder dann müssten wir etwas selbst schreiben.

Die Frage ist ernst gemeint - was bringt slf4j? Irgendwie habe ich wohl das meiste verpasst...

 

[maki]

weobei es sogar möglcih wäre dass es damals weder log4j noch slf4j gegeben hat ...

log4j gibt es seit mind. 1999

Aber ich frage mich schon wer die Weiterentwicklung anhalten kann, nur um in allen Modulen gleichzeitig etwas zu ändern was nicht gleichzeitig geschehen müsste - ist mir in 20 Jahren noch nicht vorgekommen.

Wieso die Entwicklung aufhalten?
Das sollte doch die Quellcodeverwaltung mergen können.

(Ausserdem war/ist logging immer eher eine Stiefkind

Schade.
Es muss ja nicht komplex sein, aber zumindest ein paar minimale Eigenschaften haben.

logback ist der moderne Nachfolger von log4j, SLF4J ist eine Loggingfacade.
Wie gesagt, sowohl log4j als auch logback decken deine Anforderungen ab (beides hinter SLF4J)

Sehe keinen Sinn darin nur teilweise umzusteigen, kannst den RollingFileAppender nicht sinnvoll nutzen wenn du auf System.err schreibst, hättest also keine Vorteile imho

 

[trez]

Ich weiss immer noch nicht was ein logger mehr bringen soll als schreiben auf syserr (Ausser dass hier behauptet wird das sei unschön - was aber vorerst eine Behauptung bleibt mich zu überzeugen braucht ein klein wenig mehr)

Die ältesten Sourcen sind übrigens vor 2000 entstanden - ich bin erst seit Anfangs 2010 dabei

Also zum letzten Mal und glaubtesendlichsonstverhaueichjemanden
nö bin doch immer schön friedlich:

Ein totaler Umstieg in "no time" kommt aus verschiedenen Gründen nicht in Frage. (Ja das war ein Punkt)

Die Migrationsstrategie ist gezwungenermassen folgende

Verwenden eines Loggers der auf syserr schreibt.
Umstellen in den nächsten 3-5 Monaten.
Dann austauschen des simple loggers durch einen anderen (mit "rollendem Datei anhänger" ohne an mehr als an einem Ort etwas ändern zu müssen - sonst hätte ich ein Killkriterium)

Später würde sich dann die Frage stellen, ob man syserr irgendwohin umleiten kann, wo es eine Exception gibt - na ja, so als Fallgrube für lernresitente Programmierer z.B. ein schreibgeschütztes File

 

[maki]

Hi,

ob sich der Umstieg lohnt kann ich von hier aus nicht entscheiden, Vor- und nachteile musst du schon selber abwiegen.

Was der Unterschiede und die Vorteile von einem Loggingframework gegenüber sysout und syserr sind kann man übrigens überall im Netz nachlesen (schon seit über 10 Jahren ), Tante google hilft dabei, ich muss hier niemanden von irgendwas überzeugen.

Wenn man jetzt noch ein bisschen mehr Googlen würde würde man auch Erklärungen finden, wie man System.out und System.err auf einen Log4J Appender umleitet.

Vieles ist möglich mit ein bisschen Eigeninitiative und Lernbereitschaft

 

[bygones]

Umstellen in den nächsten 3-5 Monaten.

mach wir eine Wette - du kommst in 6 Monaten wieder her und zeigst diese Umstellung.

Ich wette naemlich dass es dann auch nicht geschehen ist. Das Argument "koennen wir nicht jetzt machen, machen wir in x Monaten" ist gleichbedeutend mit "machen wir nie".... Die Annahme dass man dann mehr Zeit habe ist meist truegerisch.

aber ja - du hast einen Punkt gemacht....

also loggt ihr auch nicht mit untersch. leveln ? alles kommt auf einmal raus ? ... wer ist denn der glueckliche der das logfile analysiert ;-)

 

[trez]

mach wir eine Wette - du kommst in 6 Monaten wieder her und zeigst diese Umstellung.

Ich wette naemlich dass es dann auch nicht geschehen ist.

Das Argument "koennen wir nicht jetzt machen, machen wir in x Monaten" ist gleichbedeutend mit "machen wir nie".... Die Annahme dass man dann mehr Zeit habe ist meist truegerisch.

Es geht nicht um mehr Zeit - ich werde auch dann nicht mehr Resourcen haben. Wir machen es nicht in x Monaten sondern während x Monaten.
(Mich kopfschüttelnd fragend warum ich das zum zweiten mal erläutern muss)

Und betreffend Wette - es könnte sein, dass du meine Hartnäckigkeit unterschätzt

also loggt ihr auch nicht mit untersch. leveln ? alles kommt auf einmal raus ? ... wer ist denn der glueckliche der das logfile analysiert ;-)

Der FirstLevelSupport ;-) sieh unten.

Neben dem Error-Level gibt es nur einen Debug-Level der mit boolean-Variablen mit defaultwert = false gesteuert wird. Theoretisch ist der über einen Aufrufparamter oder einen Eintrag im configfile Systemweit veränderbar, was aber noch nie eingesetzt wurde. Die Entwickler setzen den während der Entwicklungsphase in den entsprechenden Paketen öfter mal auf true.

Im Logfile der Kunden stehen nur Fehler. Erste Frage des FirstLevelSupports (meistens ich ) hat das Logfile die Grösse 0? Nein? Schicken sie es mir bitte.

 

[trez]

Wenn man jetzt noch ein bisschen mehr Googlen würde würde man auch Erklärungen finden, wie man System.out und System.err auf einen Log4J Appender umleitet.

Vieles ist möglich mit ein bisschen Eigeninitiative und Lernbereitschaft

Hm - eine Frage der Zeit - vermutlich komme ich am Freitag Nachmittag dazu - in 10 Minuten beginnt schon die nächste Zeitverschwendung - äh - Sitzung

 

[trez]

Ich bin nur ganz flüchtig dazugekommen die Logger-Geschichte anzusehen und bin auf XML gestossen - uff - geht das auch ohne? ;-)

Ist jemand so grosszügig mir Beispielcode von der Komplxität "Hello World"++ zur Verfügung zu stellen der nicht gerade auf dem "Simple" Beispiel aufsetzt. (Glaubt mir, diese Art von Fragen stelle ich v.... ungern, aber überfüllte Stack von Pendenzen zwingen mich dazu :-( )

 

[Gast2]

Ich bin nur ganz flüchtig dazugekommen die Logger-Geschichte anzusehen und bin auf XML gestossen - uff - geht das auch ohne? ;-)

Klar, die Konfiguration kannst du bei log4j auch über nen property file machen, oder programmatisch im Code.

Ist jemand so grosszügig mir Beispielcode von der Komplxität "Hello World"++ zur Verfügung zu stellen der nicht gerade auf dem "Simple" Beispiel aufsetzt. (Glaubt mir, diese Art von Fragen stelle ich v.... ungern, aber überfüllte Stack von Pendenzen zwingen mich dazu :-( )

Logging mit Log4j

 

[trez]

Ja klar - google kenn ich auch - auf der Seite bin ich auch schon gelandet. Ist eher (("Hello World"--)--)
Wenn das alles ist, können wir genau so gut beim syserr bleiben.

EDIT:

So, wieder eine kurze Pause zwischen zwei Terminen.

Sorry, dass ich vorhin so kurz angebunden war.

Was ist nun mit der Grössenbegrenzung? (Logisch habe ich einen Verdacht, aber ohne Sourcen bzw javadoc ...)

Also ich hab zwar ein apache-log4j gefunden, aber das ist alles andere als gut. Es hat zwar jars drin (jedes mehrfach), aber die können kaum aus den mitgelieferten Sourcen entstanden sein, denn Eclipse sieht da nur noch rot und jars ohne Sourcen (Dokumentation gibt es ja typischerweise auch keine) sind eben unbrauchbar. Ach ja - es fehlt noch was mit javax und dass ein mail.jar vermisst wird, habe ich nur durch Zufall herausgefunden --- bitte bitte liebe Java-Götter, ich will doch nicht den ganzen Apache installieren müssen nur wegen einem Logger und wenn ich mich da durchhangeln muss, reichen die 3-5 Monate die ich auch schon erwähnt habe definitv nicht.

--

Also wo sind die, die da vor Kurzem so glaubhaft durchblicken lassen, dass logging sehr wichtig ist und permanent gemacht wird und die einem leicht gefruzsteten chronisch überlasteten Menschen aus der Misere helfen könnten?

 

[bygones]

Also wo sind die, die da vor Kurzem so glaubhaft durchblicken lassen, dass logging sehr wichtig ist und permanent gemacht wird und die einem leicht gefruzsteten chronisch überlasteten Menschen aus der Misere helfen könnten?

whau... sorry wenn ich sowas lese "ich will doch nicht den ganzen Apache installieren müssen nur wegen einem Logger" hoffe ich schwer dass war pure Ironie...

ich versteh nicht ganz was du machst... nimm das jar, haeng es ihn den classpath deines projektes und folge den tutorials wie man es konfiguriert....

 

[trez]

Ein Stück weit natürlich schon, aber ein ganz grosses Fragezeichen beibt bei mir schon.

Es scheint so, dass ich mich wieder einmal rechtfertigen muss:

Ich habe von derselben Webseite (sourcforge glaub ich) ein zip und ein tar.gz heruntergeladen - die Inhalte sind nicht identisch!

Dasjenige paket welche die jar-Files enthielt, habe ich als Projekt ins Eclipse genommen, denn ohne Sourcefiles bringt ein jar nicht sehr viel. Resultat: mehrere 100 Kompilationsfehler (Daher die Aussage, dass die jars wohl kaum aus den vorhandenen sourcen generiert wurden - also was helfen mir die Sourcen bzw deren javadoc?)

Aufgrund von Fehlermeldungen in Importliste weiss ich, dass z.B. javax fehlt
Aber das wimmelt alles so von Fehlern, dass ich da kaum durchgehe und alles analysiere.

Flyover muss schon funktionieren, sprich die Sourcen müssen passen, sonst kann man damit ja wohl kaum arbeiten. (Nur schon, das Beispiel das von Eike erwähnt wurde. Das überschreibt die Logfiles - es war ein reiner Verdacht, dass das mit dem boolean zu tun haben könnte - tryal an error ist nicht der vernünftigste aller Entwicklungsprozesse - da sind wir uns hoffentlich einig.)

Konfigurieren? Tutorials? Was für welche? "How to install" oder "how to use"?

Tutorials beschreiben meist nur ein Paket - für mich bleibt dann immer die Frage offen was muss wie miteinander verhängt werden, dass es auch tut.

Also bis jetzt sitze ich vor einem nicht so wirklich brauchbaren System ohne direkte Doku das nicht viel mehr macht als ein innert sehr wenigen Stunden selbst geschriebener Logger und frage mich wie gross der Aufwand noch ist, Rolling Files, automatische Zeitstempel u.ä. hinzubekomen oder ob wir doch lieber selbst etwas bauen


======
Jetzt kann ich mir etwas nicht verkneifen - ich habe schon die Einwände gelesen die Andi vor Kurzem vorgebracht hat und hatte da vorerst nur ein Kopfschütteln dafür übrig. Es scheint aber tatsächlich so ähnlich zu sein, wie er beschrieben hat. Hilfe für einfache Probleme wird hier sehr schnell und kompetent angeboten, aber sobald es etwas kompexer wird kommt nicht mehr viel Konkretes.

Ticken wir Schweizer so anders als ihr Deutschen oder woran liegt das Problem?

(Vorsicht - das Wort "anders" darf nicht wertend verstanden werden.)

 

[maki]

Ich habe von derselben Webseite (sourcforge glaub ich) ein zip und ein tar.gz heruntergeladen - die Inhalte sind nicht identisch!

Log4J ist ein Apache Projekt, keine Ahnung was du da runtergeladen hast.

Es würde wirklich helfen wenn du den Namen der Logging API nennen würdest die du da runtergeladen hast.

Dasjenige paket welche die jar-Files enthielt, habe ich als Projekt ins Eclipse genommen, denn ohne Sourcefiles bringt ein jar nicht sehr viel. Resultat: mehrere 100 Kompilationsfehler (Daher die Aussage, dass die jars wohl kaum aus den vorhandenen sourcen generiert wurden - also was helfen mir die Sourcen bzw deren javadoc?)

Man braucht Source Files nur für 3 Dinge:
1. Zum debuggen, bei einer Logging API eigentlich nie der Fall
2. Um sich von Eclipse die JavaDoc anzeigen zu lassen, bei einer Logging API eigentlich nie der Fall, log.info, warn, error etc. pp. erklären sich ja selber, Beispiele verstehen reicht
3. Um sie selber zu kompilieren, bei einer Logging API eigentlich nie der Fall

Eine Logging Framework wie Log4J sollte man nie per Javacode konfigurieren, entweder per Properies Dateien, oder per XML Dateien.

Jetzt kann ich mir etwas nicht verkneifen - ich habe schon die Einwände gelesen die Andi vor Kurzem vorgebracht hat und hatte da vorerst nur ein Kopfschütteln dafür übrig. Es scheint aber tatsächlich so ähnlich zu sein, wie er beschrieben hat. Hilfe für einfache Probleme wird hier sehr schnell und kompetent angeboten, aber sobald es etwas kompexer wird kommt nicht mehr viel Konkretes.

Ticken wir Schweizer so anders als ihr Deutschen oder woran liegt das Problem?

(Vorsicht - das Wort "anders" darf nicht wertend verstanden werden.)

Das hat nix mit Schweizer oder Deutscher zu tun, sondern damit, ob jemand Javaentwickler ist, oder nicht.
Jars einbinden, die Doku dazu lesen und Google benutzten sind nur ein paar der Dinge die jein Javaentwickler können sollte.
Andi ist auch ein Java Anfänger... wir haben hier auch Schweizer die erfahrene Javaentwickler sind, rate mal wie die das sehen?

Log4J aufsetzen dauert jedenfalls keine Stunden...

Wenn man es unbedingt selber kompilieren möchte (wozu eigentlich wenn die Jars dabei sind???) sollte man halt die notwendigen Abhängigkeiten dazu haben und grundsätzlich wissen wie man java kompiliert.

Verstehe ehrlich gesagt dein Vorgehen nicht im geringsten, wurde doch schon mehrfach erwähnt was zu tun ist:
1. Log4J runterladen
2. jars in den Classpath aufnehmen
3. konfigurieren
4. nutzen...

 

[AwsmDude]

SLF4J und Logback dem (veralteten) log4j vorziehen wenn ihr eh schon die Auswahl habt.

Logback ist gut dokumentiert: Logback Documentation
Logback und Konfiguration wird lediglich zur Laufzeit im Classpath benötigt, außer ihr wollt unbedingt über Sourcecode den Logger konfigurieren

SLF4J wird auf jeden Fall auch zum kompilieren benötigt. Die gewünschte Loggerimplementierung kann jederzeit (einfach) ausgetauscht werden, wenn lediglich SLF4J brav verwendet wird: SLF4J (slf4j-api ist die wichtige .jar)

Auch SLF4J ist gut dokumentiert: SLF4J Documentation

Was Appender anbelangt: Logback Appender
Interessant hierbei das example mit: FixedWindowRollingPolicy

Wenn du Logback für SLF4J einbindest dann diese 2 Jars: logback-classic und logback-core

In deinem Classpath sollten sich dann also folgende Jars befinden:

• slf4j-api
• logback-classic
• logback-core

Und evtl. noch eine .xml oder .groovy Datei für die Konfiguration. (logback.xml)

Selbst bauen ist wesentlich komplizierter als sich kurz in Logback einzuarbeiten. Ganz so trivial wie du wohl zu glauben scheinst ist die Implementierung eines umfangreichen Logging Frameworks nun auch wieder nicht. System.err ist beim besten Willen alles andere als ein Logging (nicht mal ein Ansatz).