Tomcat java.util.logging - keine Logs

[Sekundentakt]

Hallo Gemeinde,

ich will gerade das java.util.logging - Package mit dem Tomcat testen, bevor ich zu log4j übergehe.
Wie hier in einem anderen Thread angekündigt will ich ein umfassendes Feedback zum Einsatz des Logging-Frameworks geben.

Meine Applikation scheint laut catalina-log korrekt deployt zu werden.
Allerdings wird die via FileHandler zu erstellende Log-Datei nicht erstellt.

Ich finde sie auf dem gesamten System nicht.

Probiere ich das Ganze in der Eclipse-IDE aus, läuft es aber so wie es soll.

Apache Tomcat 6.0 - Logging in Tomcat
Die Doku half mir hier auch nicht weiter.

Hier mal ein Code-Schnipsel, welcher bei Instantiierung der App ausgeführt wird:

		    boolean append = true;
		    FileHandler handler = new FileHandler("testapp.log", append);
		    
		    // Add to the desired logger
		    Logger logger;
		    logger = Logger.getLogger("start");
		    logger.addHandler(handler);
		    logger.setLevel(Level.INFO);
		    logger.log(Level.INFO, "Application is online.");

Jetzt gibt's zwei Möglichkeiten: Entweder wird meine Applikation nicht wirklich gestartet, oder Tomcat unterdrückt da was.

Im Moment fehlt mir hier leider ein Ansatz das zu beheben.
Ideen?

Danke!

EDIT: Was mich wundert, ist das fehlende WEB-INF-Verzeichnis mit allem drum und dran im work-directory. Könnte es sein, dass ich bei der Erstellung der .war was fundamental falsch gemacht habe?

 

[Der Müde Joe]

Brauch man dafür nicht noch die Juli-Adapter?
Index of /mirror/apache/dist//tomcat/tomcat-6/v6.0.29/bin/extras

 

[Sekundentakt]

Danke!

... nur um sicherzugehen: Gibt's ne Möglichkeit zu checken, ob ne App online ist? Eine Art ping oder so?

Ich würde jetzt ungerne 10 Klassen umschreiben, weg vom Java-Logger hin zum Juli-Framework...
Oder stehe ich jetzt total aufm Schlauch?

Ich sollte vielleicht dazu sagen, dass das heute mein erster Tomcat-Tag ist.
Zuvor lief das alles out-of-the-box in der Eclipse-Glassfish-IDE.

 

[maki]

Ich sollte vielleicht dazu sagen, dass das heute mein erster Tomcat-Tag ist.

Was genau hast du denn vor?

Ein Vergleich zwischen den Logging Frameworks gibt es übrigens schon lange, von Leuten die sich damit auch auskennen die Ergebnisse sind auch klar: "Machst du Enterprise, ist log4j dein Freund"

 

[Der Müde Joe]

Wenn ich mich noch recht erinnere:
Der Tomcat benutzt inter sein eigenes Logging-Framework: Juli

in SourceCode kuck Embedded.java

import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;

Scheint so zu sein.
Möchte man das Logging umleiten, brauch man die Adapter.
Steht jedenfalls so unter log4j. Und wenn ich in die Adapter reinschaue
hats das neben AvalonLogger auch JdK14Logger und Log4JLogger
Klassen.

Da ich noch nie den util.Logger benutzt habe, kann ich dir nicht helfen.
Beim log4j ist es auf jedefall so.
(Ich benutze immer log4j (bzw sl4j)

 

[Sekundentakt]

Was genau hast du denn vor?

Ich hab' ne App geschrieben, die mit dem Standard-Java-Logging arbeitet. Die will ich erst mal antesten, weil dort wie gesagt alles über das Logging-Package läuft.

Mit der Zeit will ich zu log4j migrieren, weil alle Welt nur davon spricht, wenn's ums Loggen geht und einige Optionen dort einfach mal Sinn machen.

Es geht bei dem Test natürlich nicht primär ums Logging, ich will erst mal wissen, ob alles arbeitet wie es soll.

 

[Sekundentakt]

Scheint so zu sein.
Möchte man das Logging umleiten, brauch man die Adapter.

Ich muss noch mal genauer nachhaken: Geht's bei Dir um das Umleiten oder generell um die Erstellung von Logs?

Mein Problem ist erst mal, dass ich überhaupt keine testapp.log-Datei auf meinem System habe.
Liegt das daran, dass ich keinen Adapter nutze?

Was würde denn bei log4j passieren, wenn ich ohne Adapter arbeite? Gar nichts (buchstäblich)?

Wenn ich mit Juli arbeite, bin ich dann an den Tomcat gebunden, oder kann ich dann auch noch Jetty etc. nutzen? Ich gehe jetzt mal davon aus, dass JBoss und alle, die den Tomcat integrieren oder darauf aufbauen, keine Probleme machen werden.

Danke.

 

[Der Müde Joe]

Wir reden wahscheinlich ein wenig aneinander vorbei.

Tomcat benutzt intern: juli
intern heisst in seinen eigenen Klassen.

Wobei juli auch nur delegiert. Je nach dem was im CP vorhanden ist, ist dies noch ganz witztig.
Wenn nichts vorhanden ist, benutzt der Tomcat util.Logging.
Per default eigentlich (nach doku) commons.logging.
Added man log4j im CP wird dies genommen (juli adapter muss aber da sein)

Was man selber benutzer möchte ist eigentlich egal. (persönlich slf4j mit log4j dahinter oder auch ohne slf4j)
Ich hab mal ein kuzer Bsp geschustert um ein wenig zu spielen.
(log4j muss eigentlich im CP sein aber man kanns auch ohne laufen lassen, halt mit entsprechnder Execption
wenn das Servlet gestartet wird....auskommentieren...und gut ist...)

Dependences: die tomcat libs (je nach dem mit oder ohne juli adapter)

Nicht gerade perferkt aber zum rumspielen schön.

 

[Sekundentakt]

Hi Joe,

vielen Dank für den Codeschnipsel.

Kurz zum Verständnis:

		try {
			Thread.sleep(500000);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}

Wieso loggst Du die Exception nicht mit?

Btw.: Auf meinem Server wird immer noch keine .log-Datei geschrieben, wie eigentlich durch den FileHandler verlangt. Aber der Grund warum die App nicht lief, war nicht das Logging, sondern das Einbinden einer Servlet-API in die lib meiner Applikation.
Nachdem ich das auf eine Classpath-Einbindung reduziert habe, lief es dann.

Ich werde über das Wochenende entweder log4j einbinden oder slf4j.
Mit letzterem habe ich mich noch gar nicht beschäftigt.

Beste Grüße

 

[Der Müde Joe]

>Wieso loggst Du die Exception nicht mit?

Ist nur ein kurzer Hack das der Server oben bleibt...Sprich nach 500s war das mit dem Server ;-)
Auf diese Art natürlich nicht für produktive Zwecke benutztbar.
Thread.sleep wird ne Exception....

>Auf meinem Server wird immer noch keine .log-Datei geschrieben

Und der Server ist?... keine Schreibrechte? Sollte ein file erstellen...(jedenfalls bei mir
klappst (Ubuntu)

>Ich werde über das Wochenende entweder log4j einbinden oder slf4j.

Simple Log Facade 4 Java ist kein logger, sondern nur eine Facade (Abstraktion), welche das unterliegende Logging einer andernen API überlässt. Loggen müsste man dann immer noch mit einem bestimmter Logger. (wahlweise log4j)

 

[Sekundentakt]

Und der Server ist?... keine Schreibrechte? Sollte ein file erstellen...(jedenfalls bei mir
klappst (Ubuntu)

Gentoo.

Schreibrechte sind vorhanden soweit ich das feststellen kann.
Das Ding wird über's WE noch mal komplett debuggt.

Die Logs erscheinen wenigstens in der catalina.out - leider aber nicht in der von mir definierten Log-Datei.

Deinen EmbeddedTomcat hab ich übrigens nur lokal getestet.

Simple Log Facade 4 Java ist kein logger, sondern nur eine Facade (Abstraktion), welche das unterliegende Logging einer andernen API überlässt. Loggen müsste man dann immer noch mit einem bestimmter Logger. (wahlweise log4j)

Mit andern Worten, wenn 2012 was besseres als log4j existiert, müsste ich mit SLF4J nur einige Config-Änderungen vornehmen und hätte ein anderes Logging-Framework im Hintergrund?

Klingt erstrebenswert.

 

[Der Müde Joe]

hmm....da fällt mir grad auch nichts mehr dazu ein...(ausser bei gelegenheit wieder mal ein gentoo zu builden...)

Gehe davon aus das du (wenn du mit Gentoo fährst) die allgemeinen Tücken kennst...
Auf meinen Rechner (Ubuntu) hab ich schlicht aus Eclipse gestartet....Die utilsLogger kamm einfach in den Project-folder...(log4j ist ja nur als ConsoleAppender definiert)

>Mit andern Worten
genau....

Zudem ist slf4j effizienter...

Ums mal mit Spring auszudrücken:

If we could turn back the clock and start Spring now as a new project it would use a different logging dependency. The first choice would probably be the Simple Logging Facade for Java (SLF4J), which is also used by a lot of other tools that people use with Spring inside their
applications.
......
SLF4J is a cleaner dependency and more efficient at runtime than commons-logging because it uses
compile-time bindings instead of runtime discovery of the other logging frameworks it integrates. This
also means that you have to be more explicit about what you want to happen at runtime, and declare it or
configure it accordingly. SLF4J provides bindings to many common logging frameworks, so you can
usually choose one that you already use, and bind to that for configuration and management.
....
SLF4J provides bindings to many common logging frameworks, including JCL, and it also does the
reverse: bridges between other logging frameworks and itself.
...
A common choice might be to bridge Spring to SLF4J, and then provide explicit binding from SLF4J to
Log4J.

 

[Sekundentakt]

Gehe davon aus das du (wenn du mit Gentoo fährst) die allgemeinen Tücken kennst...

Nein. Das war ein Vorschlag von meinem Provider.
Falls es da aber Tücken gibt, nur raus mit der Sprache.
Ich kann jedenfalls mit dem User, der auch den Tomcat startet, auf der Kommandozeile Dateien verschieben, umschreiben etc. wie ich lustig bin.

Auf meinen Rechner (Ubuntu) hab ich schlicht aus Eclipse gestartet....Die utilsLogger kamm einfach in den Project-folder...(log4j ist ja nur als ConsoleAppender definiert)

So ist es auch bei mir, wenn ich es lokal in meiner Testumgebung starte. Da verwende ich allerdings Glassfish.
Nur auf dem Server wird da was verschluckt - dh. ohne Exception einfach nicht angelegt.
Im Zweifelsfall müsste mir ja wenigstens ne IOException oder so um die Ohren fliegen.

Spring will ja schon fast einen Fanclub gründen, was?

EDIT:
Wenn ich hartcodiert einen FileHandler damit beauftrage, eine Log-Datei zu schreiben, muss ich dann etwa ein logging.properties-File erstellen, damit das läuft?