Log4j und SLF4J - Laufzeitänderungen

[Sekundentakt]

Hallo,

ich suche zurzeit nach einer Möglichkeit zur Laufzeit die Optionen meiner log4j.properties-Datei zu überschreiben.

Hintergrund des Ganzen ist, dass ich auf dem DEBUG-Level sehr viele Ausgaben in bestimmten Bereichen setze, die ich wirklich nur dann benötige, wenn ich mir das Verhalten meiner Applikation unter bestimmten Umständen genauer anschauen will.

Standardmäßig ist das Log-Level INFO. Ich möchte nun aber nicht jedesmal eine .war-Datei neu kompilieren und ggf. sogar auf nen Server neu hochladen, die Applikation anhalten, neustarten usw. nur, weil ich das Log-Level verändern möchte.

Ich konnte bisher keine nützlichen Infos zu dem Thema finden, ohne dass ich log4j-Objekte instantiiere.

Hat jemand vielleicht einen Ansatz?

Beste Grüße

 

[Sekundentakt]

Keine Ideen?
Wie handelt ihr sowas denn?

 

[maki]

Wie handelt ihr sowas denn?

Ich nutze log4j direkt, ohne zus. Abstraktions API fürs Logging, wie oft stellt man das schon um? (nie!)

Für log4j sollten sich genug Beispiele finden lassen

 

[Sekundentakt]

Hi Maki,

danke für Dein Feedback!
Mit log4j ist es auch kein Thema. Da habe ich zumindest einige Beispiele gesehen.

Ich vermute mal, dass das Log-Level eine statische Variable ist.
Ich könnte mir vorstellen, dass ich eine Log4j-spezifische Klasse schreibe, die das Log-Level nach meinen Wünschen ändert.
Dann hätte ich nur diese eine Klasse, die ich austauschen müsste, wenn ich ein anderes Framework verwenden will (warum auch immer).

Ich hab's bisher aber noch nicht ausprobiert und es klingt auch etwas unschön...

 

[maki]

Dann hätte ich nur diese eine Klasse, die ich austauschen müsste, wenn ich ein anderes Framework verwenden will (warum auch immer).

Ganz ehrlich?
De Aufwand lohnt sich imho nie.
Erstens weil dieser Fall eigentlich nie eintritt (bei mir das letzte mal 2002 weil Webphere auf commons-logging besteht), und zweitens weil das mit search&replace so schnell erledigt ist, dass es sich imho nicht lohnt dafür eine Zeile code mehr zu schreiben.

Flexibilität erhöht die Komplexität, man sollte sich wirklich genau überlegen was man flexibel braucht, und das nicht auf irgendwelchen "ist vielleciht mal nützlich" Überlegungen basieren lassen, sondern auf konkreten Anforderungen.

 

[Sekundentakt]

Das klingt sinnvoll. Zurzeit gibt es allerdings eine SLF4J basierte Applikation und leider kann ich da nicht alles umstellen, zumal genutzte Frameworks ebenfalls auf SLF4J aufbauen.

Ich komme also nicht drumherum, ohne ein halbes Framework umzugestalten...

Deine Argumentation ist in sich stimmig, für das konkrete Problem kann ich darauß aber keinen Nutzen ziehen

 

[maki]

Zurzeit gibt es allerdings eine SLF4J basierte Applikation und leider kann ich da nicht alles umstellen

Das ist natürlich ein Grund, falls du direkte Refenrezen im Code auf SLF4J meinst(!).

zumal genutzte Frameworks ebenfalls auf SLF4J aufbauen.

Das macht gar nix, nutze ständig Frameworks die log4j, slf4j, commons-logging etc einsetzen, ich nutze trotzdem immer log4j

Deine Argumentation ist in sich stimmig, für das konkrete Problem kann ich darauß aber keinen Nutzen ziehen

Ja, in deinem Falle musst du es wohl wirklich so machen wie du selber vorgeschlagen hattest, was ich nicht verstehe: Wie kommt dann log4j da rein?
Da werden ja wohl kaum 2 logging Frameworks im Code verwendet in einem Projekt?

 

[AwsmDude]

Ich kann dir Logback empfehlen wenn du die Optionen während der Laufzeit umstellen willst:
Logback Home

 

[maki]

Logback sieht echt gut aus muss ich zugeben, villeicht ist es ja Zeit für mich das Logging Framework zu wechseln

 

[AwsmDude]

Ist auch vom selben Kopf wie log4j und slf4j
Habe mittlerweile komplett auf Logback umgestellt und bin sehr zufrieden. Ältere Anwendungen von mir sind noch mit log4j. Extra umgestellt habe ich jetzt nicht, aber zukünftige mache ich nur noch mit Logback.

 

[maki]

Ceki Gülcü macht gute Arbeit (auch wenn er kein einfacher Typ zu sein scheint)
Hätte man log4j einfach in die Java API übernommen hätte man sich viel Ärger und viele viele halbgare Loggingframeworks sparen können.. wurde damals aber aus "politischen" Gründen nicht gemacht wenn ich mich recht erinnere.

Die Tatsache das der SpringDM Server auch damit arbeitet bedeutet für mich dass OSGi auch kein Problem darstellt!

 

[Sekundentakt]

Ja, in deinem Falle musst du es wohl wirklich so machen wie du selber vorgeschlagen hattest, was ich nicht verstehe: Wie kommt dann log4j da rein?
Da werden ja wohl kaum 2 logging Frameworks im Code verwendet in einem Projekt?

Nein! Natürlich nicht. Aber ich nutze SLF4J mit ner log4j-Bridge, weil die eingesetzten Frameworks ebenfalls auf log4j oder slf4j aufbauen - da ergab sich das so.

Da SLF4J bei mir aber mit log4j.properties arbeitet, suche ich zurzeit nach ner Möglichkeit zur Laufzeit das Logging-Verhalten zu verändern.

Ich hoffe jetzt ist klar was ich meine .

Im Zweifelsfall muss ich wirklich in den Sourcecode reinschauen und hoffen, dass das Log-Level eine statische Variable ist. Dann brauche ich wie gesagt nur ne log4j-spezifische Klasse.

Logback schaue ich mir mal bei Gelegenheit an