Logs de inicialização do Tomcat - GRAVE: Erro filterStart como obter um rastreamento de pilha?

Quando eu inicio o Tomcat, recebo o seguinte erro:

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 estranho que os logs do Tomcat não incluam um rastreamento de pilha. Alguém tem uma sugestão de como aumentar o registro no Tomcat para obter rastreamentos de pilha para erros como este?

Verifique os logs de localhost_yyyy_mm_dd.logOR localhost.yyyy-mm-dd.logque o Tomcat cria; eles geralmente armazenam esse tipo de informação. Eu não esperaria que o stacktrace completo fosse descartado de acordo com o padrão.

crie um arquivo denominado logging.properties em WEB-INF / classes com o seguinte conteúdo:

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

O Tomcat registra o rastreamento de pilha, mas nem sempre fica claro onde os arquivos de log estão, quando o tomcat é iniciado a partir de um IDE. Quando eu inicio no IntelliJ, CATALINA_BASEestá definido como ${home}/.IntelliJIdea10/system/tomcat/Unnamed_r6-ideae os arquivos de log estão em [CATALINA_BASE]/logs.

Para ver os logs, localize os arquivos de log ou edite [CATALINA_HOME]/conf/logging.propertiespara direcionar a saída do logger do tomcat para o console. Abaixo, adicionei um segundo manipulador à configuração padrão do 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

Agora, o stacktrace completo aparece na saída do 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)
 . . .

você precisa copiar os arquivos

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

e reinicie o tomcat

Talvez seu aplicativo seja compilado com um JRE diferente do Tomcat.

Verifique java -versionem seu servidor e compile seu código com a mesma versão. Eu tive o erro porque meu JRE padrão do Eclipse era 1.6 e o ​​Tomcat usava 1.5 - isso não pode funcionar.

No CentOS 6 e Solr 4.4.0

Tive que compilar alguns arquivos lib para resolver este erro

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

Normalmente, há uma informação sobre o problema em localhost. [Data] .log. Mas às vezes não há nada neste log. Isso pode acontecer se houver configuração confusa do projeto (vários desenvolvedores trabalharam nele por um longo tempo e cada um adicionou algo de si mesmo). Enfrentei esse problema SEM nenhuma informação no log. Abordagem bastante rápida e robusta:

1. Tente remover tudo o que pode causar qualquer problema do web.xml. Você ainda pode remover tudo, exceto tag. Se o aplicativo ainda não puder ser implantado - continue.

2. Remova todos os descritores * .xml de WEB-INF / classes. Se o aplicativo não puder ser implantado - continue.

3. Remova todas as configurações de registro que você pode encontrar em seu war (logging.properties, log4j.properties). Tente implantar. Nesta etapa, obtive um erro mais informativo, mas a implantação ainda falhou.

Depois de pesquisar esse erro no Google, descobri que o projeto incluía uma versão antiga do xerces, que entrava em conflito com a versão do Tomcat (que era mais recente) e não o aplicativo a ser implantado. Após a atualização do xerces no aplicativo da web, tudo ficou bem.

Configurar o registro log4j para Tomcat é muito simples. O seguinte foi citado em http://tomcat.apache.org/tomcat-5.5-doc/logging.html :

1. Crie um arquivo chamado log4j.properties com o seguinte conteúdo e salve-o em 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. Baixe Log4J (v1.2 ou posterior) e coloque o jar log4j em $ CATALINA_HOME / common / lib.

3. Baixe o Commons Logging e coloque o commons-logging-xyzjar (não commons-logging-api-xyzjar) em $ CATALINA_HOME / common / lib com o jar log4j.
4. Inicie o Tomcat

Você também pode querer dar uma olhada em http://wiki.apache.org/tomcat/FAQ/Logging

se alguém está recebendo um erro como SEVERO: Error filterStart 29 de abril de 2013 4:49:20 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Context [/ TraceMW] inicialização falhou devido a erros anteriores

em seguida, verifique se o diretório tomcat / lib contém cors-filter-1.5.jar ou não. se você pontuar u obterá o erro acima e seu aplicativo não estará disponível.

Então, eu consegui copiar o arquivo jar de outra pasta do tomcat e não recebi o erro mencionado acima mais tarde.

Eu também tive o mesmo erro e me esforcei muito para corrigir esse problema. Passei um tempo em silêncio pesquisando no Google e encontrei a seguinte solução e meu problema foi resolvido.

o problema era devido à ausência de Bibliotecas Struts2 no caminho de implantação. A maioria das pessoas pode colocar as bibliotecas para compilação e tende a esquecer de anexar as bibliotecas necessárias para o tempo de execução. Então, adicionei as mesmas bibliotecas na montagem de implantação da Web e o problema estava DESLIGADO.

Eu tenho o mesmo problema, não consigo iniciar o aplicativo depois de implantado no tomcat. Mas, depois que copio o conjunto de jars do Struts no diretório CATALINA_HOME \ lib (Tomcat dir), ele está resolvido. Você não precisa ter esses jars em seu WEB_INF \ lib, mas precisa tê-los em seu Build Path.

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

Só queria contribuir depois de passar a última hora em um problema quase idêntico. Minha solução foi que, de alguma forma, nossos aplicativos .jar estavam corrompidos, portanto, colocar o jar de nosso servidor de desenvolvimento forneceu uma correção.

Eu tive uma questão semelhante. A dica do Renato funcionou para mim. Usei uma versão mais antiga dos arquivos de classe java (na pasta WEB-INF / classes) e o problema desapareceu. Portanto, deveria ser a incompatibilidade da versão do compilador.

Isso funcionou para mim: basta remover todas as bibliotecas e, em seguida, compilar e executar. Isso solicitaria a confirmação de seus erros em seu projeto. Execute o projeto novamente após aplicar as bibliotecas.

Geralmente, a versão do JDK do servidor será inferior à do aplicativo implantado (construído com a versão superior do jdk)

Execute o seguinte comando para mostrar os logs de catalina no terminal ---

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