Erro: jarra de servlet não carregada… Classe ofensiva: javax / servlet / Servlet.class

Estou tendo o erro a seguir:

INFO: validateJarFile (C: \ dev \ server \ tomcat6 \ webapps Sempedia \ WEB-INF \ lib \ servlet-api.jar) – jar não carregado. Veja Servlet Spec 2.3, sectoin 9.7.2. Classe ofensiva: javax / servlet / Servlet.class

Os resources existentes lá fora dizem que é devido a um conflito com o arquivo servlet.jar ou no meu caso chamado servlet-api.jar. Eu removi todos os outros projetos da pasta / webapps, peguei o arquivo servlet-api.jar que estava no diretório tomcat6 / lib e adicionei isso e apenas isso ao caminho de construção do projeto, então não vejo como ainda é um conflito.

Quando tento executar o aplicativo, recebo o seguinte rastreamento de pilha.

org.apache.jasper.JasperException: Não é possível compilar a class para JSP:

Ocorreu um erro na linha: 22 no arquivo java gerado O método getJspApplicationContext (ServletContext) é indefinido para o tipo JspFactory

Stacktrace:

org.apache.jasper.compiler.DefaultErrorHandler.javacError (DefaultErrorHandler.java:92) org.apache.jasper.compiler.ErrorDispatcher.javacError (ErrorDispatcher.java:330) org.apache.jasper.compiler.JDTCompiler.generateClass (JDTCompiler. java: 439) org.apache.jasper.compiler.Compiler.compile (Compiler.java:334) org.apache.jasper.compiler.Compiler.compile (Compiler.java:312) org.apache.jasper.compiler.Compiler. compile (Compiler.java:299) org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:586) org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:317) org.apache.jasper.servlet. JspServlet.serviceJspFile (JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service (JspServlet.java:267) javax.servlet.http.HttpServlet.service (HttpServlet.java:717)

Este é um sinal de poluição do caminho de class. As bibliotecas JSP / Servlet API são dependentes da implementação de appserver e pertencem no caso do Tomcat 6 na pasta Tomcat/lib e não devem ser movidas nem duplicadas em outro lugar. É uma receita para problemas de portabilidade e colisões no classloading como você encontrou agora. As bibliotecas no webapp têm precedência no carregamento de classs. Se o servlet-api.jar é encontrado lá, ele está procurando por suas dependencies lá, mas aparentemente eles estão faltando lá.

Você deve remover quaisquer bibliotecas específicas de appserver do Webapp/WEB-INF/lib da Webapp/WEB-INF/lib . Você deve colocar bibliotecas específicas do webapp lá. Mantenha as bibliotecas específicas do servidor no caminho de class padrão do servidor de aplicativos, que é o Tomcat/lib no seu caso. Mantenha-o intacto. Você pode, no máximo, adicionar bibliotecas que gostaria de compartilhar entre todas as aplicações web existentes, ou melhor ainda, configurar o shared.loader no Tomcat/conf/catalina.properties para isso.

Remova também quaisquer bibliotecas específicas de appserver e específicas de aplicativo web das pastas JDK/lib e JRE/lib , se houver. Eu vi muitas vezes que alguns iniciantes mover / copiar as bibliotecas lá porque “caso contrário não compila”. Você nunca deve copiar bibliotecas não específicas do JRK / JRE lá. Também é receita para problemas de portabilidade. Ao compilar classs com javac , você deve usar o argumento -cp para especificar as bibliotecas dependentes.

Atualização : no caso de um IDE (você parece usar um como você está falando sobre “caminho de compilation”), você precisa associar o projeto da web com um servidor de aplicativos. No Eclipse por exemplo, você tem a opção de fazer isso durante a criação de um Dynamic Web Project . Você precisa integrar a instância do servidor no Eclipse antes da criação do projeto. Você pode fazer isso por meio da visualização Servers (supondo que você esteja usando desenvolvedores Eclipse para Java EE , senão upgrade). Você também pode alterá-lo posteriormente por meio da input Servidores nas propriedades do projeto. Escolha um que você gostaria de usar como o servidor “padrão” e, em seguida, suas bibliotecas serão automaticamente incluídas no caminho de construção do projeto. Não há absolutamente nenhuma necessidade de copiar / movê-los em outro lugar. Veja também Como importo a API javax.servlet no meu projeto Eclipse?

Como outras respostas dizem, isso ocorre porque seu WAR inclui as classs de API de servlet, mas não deve fazê-lo.

Se você estiver usando o Maven para construir seu projeto, você vai querer dizer ao Maven para disponibilizar a API do servlet ao compilar e testar, mas não para incluí-lo no WAR. Como a documentação do Maven sobre escopo de dependência diz, você deve usar o escopo provided para a API do Servlet:

   javax.servlet servlet-api 2.5 provided  

Você também pode ter que excluir explicitamente a API do Servlet como uma dependência transitiva, se algumas de suas dependencies extraírem a API do Servlet como uma dependência de compilation:

   com.example frob-driver-core 1.0.1   servlet-api javax.servlet    

Você não tem permissão para implantar classs que substituem as definidas na Especificação de Servlet a serem fornecidas pelo contêiner da web. Você pode baixar a especificação de

http://www.jcp.org/aboutJava/communityprocess/final/jsr053/

e verifique por si mesmo. A seção 9.7.2 está na página física 63.

Servlet 2.3 é uma versão bastante antiga, indicando uma versão antiga do Tomcat. Existe algum motivo específico para você não estar usando um novo?

A primeira mensagem de erro que você recebeu foi porque o Tomcat não precisa carregar o jar de servlet porque ele já possui um e quer evitar conflitos.

Normalmente, você pode ignorar com segurança o aviso. Se você não quer que apareça, você precisa mover o jar de servlet do seu projeto, ao invés de usar o do tomcat. Ao pegar o tomcat e colocá-lo no seu projeto, você conseguiu convencer o tomcat a carregá-lo a partir do seu aplicativo da web, e não de onde ele estava esperando, causando um problema no classloader, como mencionado na resposta do BalusC.

Edit: O acima foi editado para esclarecer o que estava acontecendo uma vez que você colocou o servlet-api jar do tomcat em seu webapp (e atributo BalusC).

Na verdade eu tive esse erro e aplicativo. não foi possível iniciar, porque, por algum motivo, alguns dos jars em WEB-INF/lib tinham extensão .JAR (maiúscula) em vez de .jar . Portanto, certifique-se de que todos os jars sejam válidos.

Exclusões e dependencies provided não funcionarão em projetos filho.

Se você estiver usando inheritance em projetos Maven, inclua essa configuração no arquivo pom.xml pai. Você terá uma seção ... em seu pom.xml se estiver usando inheritance . Então você terá algo parecido com isso em seu pom.xml pai:

 some.groupId 1.0 someArtifactId pom  child-module-1 child-module-2    javax.servlet servlet-api 2.5 provided   javax.servlet.jsp jsp-api 2.1 provided