Blog

Innerhalb einer Applikation für den Weblogic Portal 10.3 Server wollte ich die Http-Session-ID in die Logausgabe konfigurieren. Dabei sollten, wenn möglich, keine Änderungen an der Domain-Installation gemacht werden.

Als Erstes nahm ich mir das Weblogic Logging System vor. Dieses bietet über commons-logging die Implementierungen JDK Logging und Log4J an. Die Admin-Console beinhaltet schon die Änderung von LogLevels zur Laufzeit. Das hörte sich schon ganz gut an und ich wähnte mich schon fast am Ende meiner Aufgabe.

Da das JDK-Logging nicht die Möglichkeit hat solche app-spezifischen Werte auszugeben, wendete ich mich sofort Log4J zu. Dort ist es ja über einen MDC (Mapped Diagnostic Context) möglich, dies abzubilden. 
Um Log4J als Implementierung anzuschalten, muss man lt. Oracle die Implementierung Log4J (über -D oder Console) auswählen und die Libs (wllog4j.jar und ein log4j.jar) in den SERVER_CLASSPATH stellen. Zusätzlich noch schnell commons-logging gegen die Weblogic-Log4J Bridge konfiguriert - fertig. 
Die beiden Libs wurden automatisch leider nur aus domainName/lib angezogen. Dies widersprach der Anforderung, die Domain-Installation unberührt zu lassen, wobei ich das zumindest nicht als so schlimm empfand. 

Schlimmer war der Umstand, dass einzig und allein die programmatische Anpassung des Output-Formats über die Log4J API möglich war. Zumindest habe ich in der Admin-Console keinen konfigurativen Weg gefunden. Der Weblogic Server gab mir da einfach keine Möglichkeit. 
Durch die programmatische Anpassung bin ich natürlich selber für das Reload von Änderungen an der Konfiguration verantwortlich. Das Ganze hatte also überall seine Ecken und Kanten und richtig zufrieden war ich mit der Lösung nicht, da ich mir ja durch die Verwendung des Subsystems eigentlich eine Arbeitserleichterung erhofft hatte.

Also ging ich gedanklich nochmal ein paar Schritte zurück und trennte mich vom Weblogic-Logging. Ich logge nun innerhalb der Anwendung über commons-logging zu einer Log4J-Implementierung. Über meine eigene log4j.xml kann ich sowohl LogLevels als auch das Format frei bestimmen.
Die Log4J XML-Datei liegt außerhalb des EAR's, damit im produktiven Betrieb die Systemadmins eine Eingriffsmöglichkeit haben. Das config-Verzeichnis des Weblogic-Adminservers war der Wunschort der Administratoren. Der Loadmechanismus musste sich also der Weblogic-API (DomainDir.getConfigDir()) bedienen, um dahin zu kommen. Ein Reload erfolgt minütlich. Die Steuerung übernimmt die Weblogic Timer API.

Am Schluss des Tages stand wieder die Erkenntnis, dass das Thema Logging nicht so trivial ist, wie es zunächst erscheint. Ich habe in beiden Lösungsvarianten viel mehr machen müssen, als ich vorher gedacht hatte.