Log4j notwendig oder nicht?

[Guest]

Ich habe für eine bereits existierende Webanwendung eine Java-Klasse zur Erweiterung dieser Webanwendung geschrieben. Die Java-Klasse habe ich in das Entsprechende Verzeichnis der Webanwendung (Tomcat) gelegt. Sie wird durch eine JSP aufgerufen.

Wenn ich das richtig verstanden habe, werden sämtliche Fehler oder System.out-Anweisungen, die in der Java-Klasse auftreten, automatisch vom Tomcat in entsprechende Log-Dateien geschrieben (stdOut bzw. stdErr).

Ein zusätzliches einbinden von Log4j in meine Java-Klasse kann ich mir doch dann eigentlich sparen oder?

 

[maki]

Du hast anscheinend den nutzen von Logging Frameworks nicht begriffen
Auch ist es schlecht, seine Fehler innerhalb der TC log Datei suchen zu müssen.

 

[Guest]

Mit Nutzen meinst du wohl die Klassifizierung... oder?

 

[maki]

Auch, damit kann man dann super Debug ausgaben produzieren, Debugger sind in einer komplexen Anwednung viel zu verwirrend, da sie viel zu viele Details zeigen.

Deine Debug ausgaben kannst du an oder abschalten, für einzelne Klassen oder ganze packages.

Auch kannst du zB dafür sogen, dass dir eine email geschick wird, wenn ein Fehler (Exception) auftritt.

Dazu musst du nur deine Konfiguration ändern (log4j.properties), dein Java Code bleibt der gleiche und muss nicht geändert werden, vorrausgesetzt du hast schon deine Logging statements drin.

Mit System.out etc ist das nicht zu steuern, auch werden System.out immer ausgeführt, auch wenn du sie gar nicht mehr haben willst, nur eine Notlösung eben.

Ich steh auf log4j, sehr einfach, effizient und doch sehr sehr nützlich

 

[Guest]

Ich habe ne Java-Klasse (und die Log4j Konfigurationsdatei) auf einen Tomcat übertragen. Sie wird dort von einer JSP aufgerufen. In Eclipse funktioniert das debuggen mit Log4j im Tomcat nichtmehr.

Woran könnte das liegen?

 

[maki]

Woran könnte das liegen?

An dir? *g*

Zeig uns doch mal deine Konfiguration.

 

[byte]

Debugger sind in einer komplexen Anwednung viel zu verwirrend, da sie viel zu viele Details zeigen.

Hm, kA wie Du das meinst, aber der Debugger ist in meinen Augen das wichtigste Tool, was wir zur Verfügung haben, um Fehler aufzuspüren und zu beheben - gerade in komplexen Anwendungen! Logger sind imo nur zum Protokollieren sinnvoll.

 

[SlaterB]

Problem tritt mit 345. Durchlauf einer Schleife x im 9. Aufruf einer Operation y auf,
und zwar wenn Variable z unter 17.5 fällt

Logging:
if (z < 17.5) {
System.out.println(..);
}


was machst du im Debugging-Tool?
was machst du wenn du 3-4 Stellen gleichzeitig untersuchst/ abwechselnd/ zwei Tage später nochmal?

Logging bleibt bestehen bzw. ist mit simpler Konfiguration oder gar Auskommentierung bestmöglich zu handeln,
was kann da ein Debugging-Tool?

was machst du bei einem Ablauf über 2 Min., bei dem du 10 Zwischenwerte in 10 Unterprogrammen anschauen willst,
um langsam den Fehler einzugrenzen?
ohne Logging läuft gar nix

 

[byte]

Problem tritt mit 345. Durchlauf einer Schleife x im 9. Aufruf einer Operation y auf,
und zwar wenn Variable z unter 17.5 fällt

Logging:
if (z < 17.5) {
System.out.println(..);
}


was machst du im Debugging-Tool?

Conditional Breakpoint oder Hitcount einstellen. :bae:

was machst du wenn du 3-4 Stellen gleichzeitig untersuchst/ abwechselnd

Mehrere Breakpoints setzen? Oder direkt Variablenwerte on the fly auswerten lassen (siehe Expressions View in Eclipse).

Logging bleibt bestehen bzw. ist mit simpler Konfiguration oder gar Auskommentierung bestmöglich zu handeln,
was kann da ein Debugging-Tool?

was machst du bei einem Ablauf über 2 Min., bei dem du 10 Zwischenwerte in 10 Unterprogrammen anschauen willst,
um langsam den Fehler einzugrenzen?
ohne Logging läuft gar nix

Das verstehe ich unter Protokollierung (passives Aufzeichnen von Informationen über Zeit). Auf den Großteil der Anwendungen trifft das aber nicht zu.

 

[SlaterB]

also den direkten Code in einem anderen Tool nachbauen,
na wenn das sinnvoll ist..

entweder drei Stellen im Code ändern, in dem man sowieso die ganze Zeit arbeitet
z < 17.5 wird in Sekundenbruchteilen z < 18
oder durch irgendwelche schrägen Menüs wandern?,
mit einem zweiten Berg Konfigurationen, der an einem anderen Workspace/ einem anderen Arbeitsplatz/ einer neuen Programmversion/ einer anderen Entwicklungsumgebung/ Programmiersprache nicht mehr da ist..

Java ist so mächtig, lass doch Java selber arbeiten
was spart ein Debugger so ungemein? einzig sinnvoll scheint mir die Funktion, an einer bestimmten Stelle anzuhalten und dort individuell alle Inhalte anzuschauen/ schrittweise herumzuspringen,
dies wiederum zähle ich unter 'Auf den Großteil der Anwendungen trifft das aber nicht zu.'

 

[byte]

Wie stellst Du Dir die Fehlersuche in einer komplexen Software, wo x Leute mitarbeiten, denn vor? Willst Du erstmal alle 5000 Klassen mit Debug-Ausgaben vollschreiben, um dann den Fehler zu finden? :roll: Ich setze lieber mit einem Klick an die Stelle einen Breakpoint, wo ich den Fehler vermute und debugge dann, bis ich den Fehler gefunden habe.

Ich sage nicht, dass Logging unsinnig ist, aber wenns um die Fehlersuche geht, dann ist alles andere als der Debugger ineffizient. Ich wage einfach mal zu bezweifeln, das jemand der gegenteiliges behauptet, schon mal richtig mit dem Debugger gearbeitet hat.

 

[SlaterB]

> Willst Du erstmal alle 5000 Klassen mit Debug-Ausgaben vollschreiben, um dann den Fehler zu finden?

wieso 5000?
da wo die Ausgabe hin muss, da kommt die Ausgabe hin genau wie der Breakpoint

> Ich setze lieber mit einem Klick an die Stelle einen Breakpoint

und genau dieser eine Klick geht doch nicht,
if (z < 17.5) {
System.out.println(..);
}
ist schnell geschrieben, auch schnell an 5 andere Stellen kopiert,
aber das gleiche als Breakpoint zu definieren?..
durch irgendwelche Menüs wandern, in einem leeren Fenster (immerhin mit code assist) irgendwie den gleichen Code nachbauen?..
man stelle sich vor, man müßte jede Operation einer Java-Klasse in einem eigenen Fenster bauen..

 

[maki]

Willst Du erstmal alle 5000 Klassen mit Debug-Ausgaben vollschreiben, um dann den Fehler zu finden?

Deshalb sollte man sie auch gleich beim erstellen miteinbauen
Nachträglich Loggingstatements einzubauen ist ein Sch....job, aber manchmal notwendig, wenn die Entwickler das "vergessen" haben.

Es gibt Umgebungen, die man nicht Debuggen kann, dazu gehört ein App Server wie JBoss, da braucht man seine Unittests und ist ist bis auf die Logging Ausgaben Blind.
Ohne eine gute Logging Strategie ist man da aufgeschmissen.

Oft reicht es, beim Aufruf einer Methode den Namen der Methode und die Parameter mitausgeben zu lassen, ausführlicher wenn man beim Beenden des Ausrufes noch einen Status zurückgibt, oder gar in Schleifen aktuelle Werte loggt, natürlich nur falls geloggt werden soll, um die Performance zu schonen

So ein Debuglog liest sich wie ein Drehbuch zum Auftritt eines Fehlers, so spart man sich meistens den Debugger

Ansonsten ist es interessant zu sehen wie sich ein System zur Laufzeit mit nebenläufigen Zugriffen verhält.

 

[byte]

Wieso kannst Du Anwendungen über einen App.Server nicht debuggen? Remote Debugging heisst das Stichwort in Eclipse. Jeder vernünftige App.Server (so auch JBoss) bietet entsprechende Hooks dafür an.

 

[maki]

Dein Link zeigt das Debuggen eines Servlets
Bei einer EJB sieht es anders aus, es geht schon, ist allerdings nicht sinnvoll und kompliziert, kann/soll man ein "Managed Environment" einfach so anhalten?

Logging, das Protokollieren von Statusinformationen kann einiges mehr zur Fehlersuche beitragen als Debuggen in einer "künstlichen" Umgebung zu einem vollkommen anderen Zeitpunkt, auch schliessen sich die beiden nicht gegenseitig aus.

Je bessere Logging Infos ich zur Verfügung habe, umso weniger debugge ich, Logs lesen fällt mir einfacher als debuggen

 

[SlaterB]

aber hey, als Debugger kann man eben bestimmte Produkte nicht einsetzen, die wandern in den Müll und fertig,
da bin ich lieber kein Debugger..

 

[byte]

Kein Grund polemisch zu werden. :roll:
Ich habe nie behauptet, dass es nicht auf Fälle gibt, wo der Debugger versagt. In den meisten Fällen ist es halt nicht so, da bist Du (falls geübt) mit dem Debugger viel schneller. Wir können uns gerne mal zu einem Contest treffen: Fehlersuche Debugger vs Logging. :lol: