2016-05-14 5 views
0

Kürzlich wurde mir die Aufgabe erteilt, eine Java-Anwendung zu erweitern, die in WebSphere 6.0 in Entwicklungs- und Produktionsumgebungen implementiert wurde. Der Code hat einen Fehler. Es greift auf eine Datenbankspalte mit dem falschen Namen zu. Der Code fängt die Ausnahme ab, führt eine printStackTrace() aus und fährt fort.Ausnahmestapel-Trace erscheint nicht in WebSphere-Protokollen

In der Entwicklungsumgebung sehe ich den Stack-Trace der Ausnahme in den WebSphere-Protokollen, aber ich sehe sie nicht in den Protokollen für die Produktionsumgebung.

Ich habe keine Administratorrechte für WebSphere in der Produktionsumgebung. Ich kann nur die Protokolldateien sehen. Um sicherzustellen, dass in beiden Umgebungen derselbe Code ausgeführt wird, habe ich die EAR-Datei von der Produktionsumgebung (von der Gruppe, die den Server verwaltet) bezogen und sie in der Entwicklungsumgebung bereitgestellt.

Meine Frage ist, wenn ich den gleichen Code in beiden Umgebungen ausführen, ist es möglich, den Stack-Trace in Protokollen in einer Umgebung und nicht in der anderen zu sehen?

Dank

+0

dies eine mögliche Erklärung dafür ist, http://stackoverflow.com/a/3010106/3215527 – wero

+2

Wenn der gleiche Zustand auftritt, ist es unwahrscheinlich, dass einige Server Config unterdrückt die Stack-Trace. – covener

+0

Ist es möglich, dass die Protokolle, auf die Sie Zugriff haben, nicht die richtigen sind, sondern stattdessen für einen anderen Server? Ist es eine Clusterumgebung? – DanielBarbarian

Antwort

0

Die Umgebung ist für das Verhalten des gesamten Systems ganz Determinante, wenn Sie also direkt von einer ART-Umgebung eine EAR-Datei nehmen, könnten Sie sicher stellen Sie es nicht auf einer anderen Umgebung (wie DEV oder UAT) ohne mehrere Konfigurationsänderungen durchzuführen, sowohl in der .ear-Datei als auch in WebSphere.

Nichtsdestotrotz denke ich, dass das Problem hier die Protokolllevelkonfiguration sein könnte. Normalerweise haben wir in niedrigeren Umgebungen eine Konfiguration mit hoher Protokollstufe als "alles" oder "feinste", um alle Fehler zu debuggen, so dass Sie viele und verschiedene Protokolleingaben sehen können. Auf der anderen Seite haben wir Produktionsumgebungen, in denen die Anwendung nach mehreren Tests in niedrigeren Umgebungen korrekt ausgeführt werden sollte. Daher wird der Protokollierungslevel oft auf "fatal", "shree" oder "warning" reduziert, um nur wichtige Fehler zu erhalten Beeinträchtigung der Anwendungs-/Systemleistung. Überprüfen Sie Ihre Log-Level-Konfiguration in beiden Umgebungen und vergleichen Sie sie, es wird sicherlich anders sein (vielleicht müssen Sie jemanden mit Administratorrechten in der Produktion um Hilfe bitten, zu weniger, wenn Sie es ändern wollen).

Inzwischen WebSphere 6.0 von Unterstützung ist seit 30. September 2010;)