Registros de inicio de Tomcat - GRAVE: filtro de error ¿Comenzar cómo obtener un seguimiento de pila?

Cuando inicio Tomcat, aparece el siguiente error:

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

Parece extraño que los registros de Tomcat no incluyan un seguimiento de pila. ¿Alguien tiene alguna sugerencia sobre cómo aumentar el registro en Tomcat para obtener seguimientos de pila para errores como este?

Verifique los registros localhost_yyyy_mm_dd.logOR localhost.yyyy-mm-dd.logque crea Tomcat, estos suelen almacenar ese tipo de información. No esperaría que el stacktrace completo se volviera estándar.

cree un archivo llamado logging.properties en WEB-INF / classes con el siguiente contenido:

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

Tomcat registra el seguimiento de la pila, pero no siempre está claro dónde están los archivos de registro, cuando tomcat se inicia desde un IDE. Cuando lo inicio desde IntelliJ, CATALINA_BASEestá configurado en ${home}/.IntelliJIdea10/system/tomcat/Unnamed_r6-ideay los archivos de registro están en formato [CATALINA_BASE]/logs.

Para ver los registros, ubique los archivos de registro o edítelos [CATALINA_HOME]/conf/logging.propertiespara dirigir la salida del registrador de tomcat a la consola. A continuación, agregué un segundo controlador a la configuración predeterminada de tomcat:

 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

Ahora el stacktrace completo aparece en la salida de IntelliJ:

 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)
 . . .

necesitas copiar los archivos

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

y luego reinicia tomcat

Quizás su aplicación esté compilada con un JRE diferente al de Tomcat.

Verifique java -versionsu servidor y luego compile su código con la misma versión. Tuve el error porque mi JRE estándar de Eclipse era 1.6 y Tomcat usó 1.5; esto no puede funcionar.

En CentOS 6 y Solr 4.4.0

Tuve que compilar algunos archivos lib para solucionar este error

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

Por lo general, hay información sobre el problema en localhost. [Fecha] .log. Pero a veces no hay nada en este registro. Esto puede suceder si hay una configuración desordenada del proyecto (varios desarrolladores trabajaron en él durante mucho tiempo y cada uno agregó algo de sí mismo). Me enfrenté a este problema SIN ninguna información en el registro. Enfoque bastante rápido y robusto:

1. Intente eliminar todo lo que pueda causar algún problema de web.xml. Incluso puede eliminar todo excepto la etiqueta. Si la aplicación aún no se puede implementar, continúe.

2. Elimine todos los descriptores * .xml de WEB-INF / classes. Si la aplicación no se puede implementar, continúe.

3. Elimine toda la configuración de registro que pueda encontrar en su guerra (logging.properties, log4j.properties). Intente implementar. En este paso, tengo un error más informativo, pero la implementación aún falla.

Después de buscar en Google este error, descubrí que el proyecto incluía una versión anterior de xerces, que chocaba con la versión de Tomcat (que era más reciente) y no era la aplicación que se iba a implementar. Después de la actualización de xerces en la aplicación web, todo salió bien.

Configurar el registro log4j para Tomcat es bastante simple. Lo siguiente se cita de http://tomcat.apache.org/tomcat-5.5-doc/logging.html :

1. Cree un archivo llamado log4j.properties con el siguiente contenido y guárdelo en 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. Descargue Log4J (v1.2 o posterior) y coloque el jar log4j en $ CATALINA_HOME / common / lib.

3. Descargue Commons Logging y coloque commons-logging-xyzjar (no commons-logging-api-xyzjar) en $ CATALINA_HOME / common / lib con el jar log4j.
4. Iniciar Tomcat

Es posible que también desee echar un vistazo a http://wiki.apache.org/tomcat/FAQ/Logging

si alguien recibe un error como SEVERE: Error filterStart 29 de abril de 2013 4:49:20 PM org.apache.catalina.core.StandardContext startInternal SEVERE: El inicio del contexto [/ TraceMW] falló debido a errores anteriores

luego verifique si su directorio tomcat / lib contiene cors-filter-1.5.jar o no. si no tiene u obtendrá el error anterior y su aplicación no estará disponible.

Entonces, logré copiar el archivo jar de otra carpeta de tomcat y no obtuve el error mencionado más adelante.

Yo también obtuve el mismo error y luché mucho para solucionar este problema. Pasé un poco de tiempo buscando en Google y encontré la siguiente solución y mi problema se resolvió.

el problema se debía a que faltaban las bibliotecas Struts2 en la ruta de implementación. La mayoría de la gente puede poner las bibliotecas para la compilación y tienden a olvidarse de adjuntar las bibliotecas necesarias para el tiempo de ejecución. Así que agregué las mismas bibliotecas en el ensamblaje de implementación web y el problema estaba DESACTIVADO.

Tengo el mismo problema, no puedo iniciar la aplicación una vez implementada en Tomcat. Pero, una vez que copie el conjunto de jarras de Struts en el directorio CATALINA_HOME \ lib (Tomcat dir), se resuelve. No necesita tener estos archivos jar en su WEB_INF \ lib, pero debe tenerlos en su ruta de compilación.

commons-fileupload-1.2.1.jar

commons-io-1.3.2.jar

freemarker-2.3.16.jar

javassist-3.11.0.GA.jar

struts2-convention-plugin-2.2.1.jar

struts2-core-2.2.1.jar

xwork-core-2.2.1.jar

Solo quería contribuir después de pasar la última hora en un problema casi idéntico. Mi solución fue que de alguna manera nuestro .jar de aplicaciones estaba dañado, por lo que colocar el jar desde nuestro servidor de desarrollo proporcionó una solución.

Tuve un problema similar. El consejo de Renato funcionó para mí. Usé una versión anterior de los archivos de clase de Java (en la carpeta WEB-INF / classes) y el problema desapareció. Entonces, debería haber sido la falta de coincidencia de la versión del compilador.

Esto funcionó para mí: simplemente elimine todas las bibliotecas y luego compile y ejecute. Le indicaría que hay errores en la confirmación de su proyecto. Vuelva a ejecutar el proyecto después de aplicar las bibliotecas.

Generalmente, la versión de JDK del servidor será inferior a la aplicación implementada (construida con una versión de jdk superior)

Ejecute el siguiente comando para mostrar los registros de catalina en la terminal ---

sh start-camunda.sh; tail -f server/apache-tomcat-8.0.24/logs/catalina.out