Tomcat-Startprotokolle - SEVERE: Fehler filterStart Wie erhalte ich einen Stack-Trace?


96

Wenn ich Tomcat starte, wird folgende Fehlermeldung angezeigt:

Jun 10, 2010 5:17:25 PM org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
Jun 10, 2010 5:17:25 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/mywebapplication] startup failed due to previous errors

Es scheint seltsam, dass die Protokolle für Tomcat keinen Stack-Trace enthalten. Hat jemand einen Vorschlag, wie die Protokollierung in Tomcat erhöht werden kann, um Stapelspuren für solche Fehler zu erhalten?


1
Ich verwende Guice-Servlet und durch Ausprobieren meiner Setup-Methode für dieses Framework konnte ich alle Ausnahmen abfangen und erneut auslösen, nachdem ich mich selbst angemeldet hatte. Ich musste immer noch blind debuggen, damit der Filter von Guice-Servlet funktioniert, aber alles, was dazu hinzugefügt wurde, scheint einfach zu funktionieren.
benstpierre

1
Es scheint, dass Stack-Traces zu stdout gehen, aber Intellij liest das stdout für Tomcat nicht. tomcat.apache.org/tomcat-6.0-doc/logging.html Ich muss stdout in tomcat in eine Datei umleiten, damit Intellij sie anzeigen kann.
Benstpierre

Antworten:


138

Überprüfen Sie die von Tomcat erstellten localhost_yyyy_mm_dd.logODER- localhost.yyyy-mm-dd.logProtokolle. Diese speichern normalerweise diese Art von Informationen. Ich würde nicht erwarten, dass der gesamte Stacktrace auf Standard out ausgegeben wird.


Meine Instanz von Tomcat 5.5 schreibt diese Datei nicht.
Arne Evertsson

3
Bis zu diesem Moment hat "error filterStart" meine Albträume geplagt ... NICHT MEHR! Du rockst!
Cody S

Eines dieser Dinge entdecken Sie gerne während der Entwicklung. Vielen Dank.
Francisco Lozano

Mein Tomcat 6 (mit Standard-Setup) schreibt nie etwas in die Datei. Ich musste ConsoleHandler aktivieren, um zu lesen, was schief gelaufen ist, und das hat die Ausnahmen in die Catalina-Ausgabedatei geschrieben.

2
@mattblang werfen Sie einen Blick auf $ TOMCAT_HOME / conf / logging.properties. Die Standardeinstellung ist nicht intuitiv.
Matt B

80

Erstellen Sie eine Datei mit dem Namen logging.properties in WEB-INF / classes mit folgendem Inhalt:

org.apache.catalina.core.ContainerBase.[Catalina].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler

Beachten Sie, dass Sie, wenn Sie kein Klassenverzeichnis in WEB-INF haben, einfach eines erstellen können und es gut funktioniert.
Muhd

21

Tomcat protokolliert zwar den Stacktrace, es ist jedoch nicht immer klar, wo sich die Protokolldateien befinden, wenn Tomcat von einer IDE aus gestartet wird. Wenn ich es von IntelliJ aus starte, CATALINA_BASEist es auf gesetzt ${home}/.IntelliJIdea10/system/tomcat/Unnamed_r6-ideaund die Protokolldateien sind in[CATALINA_BASE]/logs .

Um die Protokolle anzuzeigen, suchen Sie entweder die Protokolldateien oder bearbeiten Sie sie [CATALINA_HOME]/conf/logging.properties, um die Tomcat-Logger-Ausgabe an die Konsole zu leiten. Unten habe ich der Standard-Tomcat-Konfiguration einen zweiten Handler hinzugefügt:

 org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
 org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

Jetzt wird die vollständige Stapelverfolgung in der IntelliJ-Ausgabe angezeigt:

 Dec 27, 2011 12:02:45 PM org.apache.catalina.core.StandardContext filterStart
 SEVERE: Exception starting filter filterChainProxy
 org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'filterChainProxy' is defined   at
 org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:529)
 . . .

9

Sie müssen die Dateien kopieren

cp /path/to/solr/example/lib/ext/* /path/to/tomcat/lib
cp /path/to/solr/example/resources/* /path/to/tomcat/lib // or inside extracted solr

und starten Sie dann Tomcat neu


3
yay, das hat mich gerettet! . Es wäre auch eine gute Idee, sich die /path/to/solr/example/resources/log4j.properties anzusehen und Ihr Protokollverzeichnis zu bearbeiten
user9869932

5

Möglicherweise wurde Ihre Anwendung mit einer anderen JRE als Tomcat kompiliert.

Überprüfen Sie java -versionIhren Server und kompilieren Sie Ihren Code mit derselben Version. Ich hatte den Fehler, weil meine Eclipse-Standard-JRE 1.6 war und Tomcat 1.5 verwendete - das kann nicht funktionieren.


2

In CentOS 6 und Solr 4.4.0

Ich musste einige lib-Dateien komponieren, um diesen Fehler zu beheben

cp ~/solr-4.4.0/example/lib/ext/* /usr/share/tomcat6/lib/

Dies löste das Problem auch für mich. Ubuntu 14.04 und Solr 4.8.1 und Tomcat 7.
Cjungel

2

Normalerweise gibt es Informationen zu dem Problem in localhost. [Date] .log. Aber manchmal ist nichts in diesem Protokoll. Dies kann passieren, wenn die Konfiguration des Projekts fehlerhaft ist (mehrere Entwickler haben lange daran gearbeitet und jeder hat etwas von sich selbst hinzugefügt). Ich habe dieses Problem OHNE Informationen im Protokoll konfrontiert. Eher schneller und robuster Ansatz:

  1. Versuchen Sie, alles, was Probleme verursachen kann, aus web.xml zu entfernen. Sie können sogar alles außer Tag entfernen. Wenn die Anwendung immer noch nicht bereitgestellt werden kann, fahren Sie fort.

  2. Entfernen Sie jeden * .xml-Deskriptor aus WEB-INF / classes. Wenn die Anwendung nicht bereitgestellt werden kann, fahren Sie fort.

  3. Entfernen Sie alle Protokollierungskonfigurationen, die Sie in Ihrem Krieg finden (logging.properties, log4j.properties). Versuchen Sie zu implementieren. In diesem Schritt habe ich einen informativeren Fehler erhalten, aber die Bereitstellung ist immer noch fehlgeschlagen.

Nachdem ich nach diesem Fehler gegoogelt hatte, stellte ich fest, dass das Projekt eine alte Version von xerces enthielt, die mit der neueren Version von Tomcat kollidierte und die zu implementierende Anwendung nicht enthielt. Nach dem Upgrade von xerces in der Webanwendung wurde alles in Ordnung.


1

Das Einrichten der log4j-Protokollierung für Tomcat ist ziemlich einfach. Folgendes wird aus http://tomcat.apache.org/tomcat-5.5-doc/logging.html zitiert :

  1. Erstellen Sie eine Datei mit dem Namen log4j.properties mit dem folgenden Inhalt und speichern Sie sie in common / classes.

              log4j.rootLogger=DEBUG, R 
              log4j.appender.R=org.apache.log4j.RollingFileAppender 
              log4j.appender.R.File=${catalina.home}/logs/tomcat.log 
              log4j.appender.R.MaxFileSize=10MB 
              log4j.appender.R.MaxBackupIndex=10 
              log4j.appender.R.layout=org.apache.log4j.PatternLayout 
              log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
  2. Laden Sie Log4J (v1.2 oder höher) herunter und platzieren Sie das log4j-Glas in $ CATALINA_HOME / common / lib.

  3. Laden Sie Commons Logging herunter und platzieren Sie das commons-logging-xyzjar (nicht das commons-logging-api-xyzjar) in $ CATALINA_HOME / common / lib mit dem log4j-Jar.
  4. Starten Sie Tomcat

Vielleicht möchten Sie auch einen Blick auf http://wiki.apache.org/tomcat/FAQ/Logging werfen


Wird dies dazu führen, dass Bereitstellungsausnahmen tatsächlich ordnungsgemäß protokolliert werden?
Benstpierre

Ja. Ich habe genau diese Methode verwendet, um Ursachen für Probleme während der Bereitstellung zu finden.
Tommi

1
Es tut mir leid, aber die Protokolldatei ist mit einer Protokollstufe von DEBUG undurchdringlich. Es enthält einige Ausnahmen, die nichts mit dem Problem zu tun zu haben scheinen - was ich in meinem Fall für ein Struts-Problem halte.
Arne Evertsson

1

Wenn jemand einen Fehler wie SEVERE erhält: Fehler filterStart 29. April 2013, 16:49:20 Uhr org.apache.catalina.core.StandardContext startInternal SEVERE: Der Start von Context [/ TraceMW] ist aufgrund vorheriger Fehler fehlgeschlagen

Überprüfen Sie dann bitte, ob Ihr tomcat / lib-Verzeichnis enthält cors-filter-1.5.jar enthält oder nicht. Wenn Sie einen Punkt haben, wird der obige Fehler angezeigt und Ihre Anwendung ist nicht verfügbar.

Also habe ich es gerade geschafft, die JAR-Datei aus einem anderen Tomcat-Ordner zu kopieren und habe den oben genannten Fehler später nicht erhalten.


1

Auch ich habe den gleichen Fehler erhalten und mich sehr bemüht, dieses Problem zu beheben. Verbrachte ein wenig Zeit mit der Suche in Google und fand die folgende Lösung, und mein Problem wurde behoben.

Das Problem war darauf zurückzuführen, dass Struts2-Bibliotheken im Bereitstellungspfad fehlten. Die meisten Leute stellen die Bibliotheken möglicherweise zur Kompilierung bereit und vergessen häufig, die erforderlichen Bibliotheken zur Laufzeit anzuhängen. Also habe ich die gleichen Bibliotheken in der Webbereitstellungsassembly hinzugefügt, und das Problem war AUS.


1

Ich habe das gleiche Problem und konnte die Anwendung nicht starten, sobald sie in Tomcat bereitgestellt wurde. Sobald ich den Struts-Satz von Gläsern in das Verzeichnis CATALINA_HOME \ lib (Tomcat-Verzeichnis) kopiere, wird er aufgelöst. Sie müssen diese Gläser nicht in Ihrer WEB_INF \ lib haben, aber Sie müssen sie in Ihrem Build-Pfad haben.

commons-fileupload-1.2.1.jar

commons-io-1.3.2.jar

freemarker-2.3.16.jar

javassist-3.11.0.GA.jar

struts2-konvention-plugin-2.2.1.jar

struts2-core-2.2.1.jar

xwork-core-2.2.1.jar


0

Ich wollte nur einen Beitrag leisten, nachdem ich die letzte Stunde mit einem fast identischen Problem verbracht hatte. Meine Lösung war, dass unsere .jar-Anwendung irgendwie beschädigt war, sodass das Platzieren des JARs von unserem Entwicklungsserver eine Lösung bot.


0

Ich hatte ein ähnliches Problem. Renatos Tipp hat bei mir funktioniert. Ich habe eine ältere Version von Java-Klassendateien (im Ordner WEB-INF / classes) verwendet und das Problem ist verschwunden. Es sollte also die Nichtübereinstimmung der Compilerversion gewesen sein.


0

Dies hat den Trick für mich getan: Entfernen Sie einfach alle Bibliotheken und kompilieren Sie sie und führen Sie sie aus. Es würde dazu führen, dass Fehler in Ihrem Projekt bestätigt werden. Führen Sie das Projekt erneut aus, nachdem Sie die Bibliotheken angewendet haben.


0

Im Allgemeinen ist die Server-JDK-Version niedriger als die bereitgestellte Anwendung (erstellt mit einer höheren JDK-Version).


-1

Führen Sie den folgenden Befehl aus, um Catalina-Protokolle auf dem Terminal anzuzeigen ---

sh start-camunda.sh; tail -f server/apache-tomcat-8.0.24/logs/catalina.out
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.