Error: Servlet Jar no cargado... Clase ofensiva: javax/servlet/Servlet.class

heroku java tomcat

Question

Obtuve el siguiente error:

INFO: validateJarFile (C: / dev / servidor / tomcat6 / webapps Sempedia / WEB-INF / lib / servlet-api.jar) - jar no cargado. Ver Servlet Spec 2.3, sectoin 9.7.2. Clase ofensiva: javax / servlet / Servlet.class

Los recursos existentes dicen que se debe a un conflicto con el servlet.jar o en mi caso llamado archivo servlet-api.jar. He eliminado todos los otros proyectos de la carpeta / webapps, tomé el archivo servlet-api.jar que estaba en el directorio tomcat6 / lib y lo agregué solo a la ruta de compilación del proyecto, por lo que no puedo ver cómo sigue siendo un conflicto

Cuando intento ejecutar la aplicación obtengo el siguiente seguimiento de la pila.

org.apache.jasper.JasperException: no se puede compilar la clase para JSP:

Se produjo un error en la línea: 22 en el archivo java generado. El método getJspApplicationContext (ServletContext) no está definido para el 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)

Answer 1

Como dicen otras respuestas, esto se debe a que su WAR incluye las clases de la API de servlet, pero no debería hacerlo.

Si está utilizando Maven para construir su proyecto, querrá decirle a Maven que ponga a disposición la API de servlet al compilar y probar, pero que no la incluya en WAR. Como dice la documentación de Maven sobre el alcance de la dependencia , debe usar el alcance provided para la API de Servlet:

    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>servlet-api</artifactId>
        <version>2.5</version>
        <scope>provided</scope>
    </dependency>

También podría tener que excluir explícitamente la API de Servlet como una dependencia transitiva, si algunas de sus dependencias extraen la API de Servlet como una dependencia de compilación:

    <dependency>
        <groupId>com.example</groupId>
        <artifactId>frob-driver-core</artifactId>
        <version>1.0.1</version>
        <exclusions>
            <exclusion>
                <artifactId>servlet-api</artifactId>
                <groupId>javax.servlet</groupId>
            </exclusion>
        </exclusions>
    </dependency>

Answer 2

De hecho, tuve ese error y aplicación. no se pudo iniciar porque, por alguna razón, algunos de los .JAR WEB-INF/lib tenían .JAR (mayúscula) en lugar de .jar . Así que asegúrese de que todos los frascos sean válidos.

Answer 3

El primer mensaje de error que recibiste fue porque Tomcat no necesita cargar el jar de servlet porque ya tiene uno y quiere evitar conflictos.

Por lo general, puede ignorar la advertencia de forma segura. Si no desea que aparezca, debe mover el jar de servlet de su proyecto, en lugar de usar el de tomcat. Al tomar el tomcat uno y ponerlo en su proyecto, ha logrado convencer a tomcat para que lo cargue desde su aplicación web en lugar de desde donde lo esperaba, causando un problema de cargador de clase como se menciona en la respuesta del BalusC.

Editar: Lo anterior fue editado para aclarar lo que sucedía una vez que colocaste el tarro servlet-api de tomcat en tu aplicación web (y le atribuyeste BalusC).

Answer 4

No tiene permitido implementar clases que anulen las definidas en la Especificación del servlet que debe proporcionar el contenedor web. Puede descargar la especificación de

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

y compruébalo tú mismo La Sección 9.7.2 está en la página física 63.

Servlet 2.3 es una versión bastante antigua que indica una versión antigua de Tomcat. ¿Hay alguna razón en particular por la que no estás utilizando una más nueva?

Answer 5

Las exclusiones y dependencias provided no funcionarán en proyectos secundarios.

Si está utilizando la herencia en proyectos de Maven, debe incluir esta configuración en el archivo pom.xml principal. Tendrás una sección <parent>...</parent> en tu pom.xml si estás utilizando la herencia . Así que tendrás algo como esto en tu pom.xml padre:

<groupId>some.groupId</groupId>
<version>1.0</version>
<artifactId>someArtifactId</artifactId>
<packaging>pom</packaging>
<modules>
    <module>child-module-1</module>
    <module>child-module-2</module>
</modules>
<dependencies>
    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>servlet-api</artifactId>
        <version>2.5</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>javax.servlet.jsp</groupId>
        <artifactId>jsp-api</artifactId>
        <version>2.1</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

Answer 6

Este es un signo de contaminación de classpath. Las bibliotecas de la API JSP / Servlet dependen de la implementación del servidor de aplicaciones y pertenecen en el caso de Tomcat 6 en la carpeta Tomcat/lib y de ninguna manera deben moverse ni duplicarse en otro lugar. Es la receta para problemas de portabilidad y colisiones en la carga de clases como lo ha visto ahora. Las bibliotecas en la aplicación web tienen prioridad en la carga de clases. Si el servlet-api.jar se encuentra allí, a su vez está buscando sus dependencias allí, pero al parecer faltaban allí.

Debe eliminar las bibliotecas específicas del Webapp/WEB-INF/lib de Webapp/WEB-INF/lib de Webapp/WEB-INF/lib de la aplicación web. Solo debe colocar bibliotecas específicas de la aplicación web allí. Mantenga las bibliotecas específicas del servidor de aplicaciones en el classpath predeterminado del servidor de aplicaciones, que es el Tomcat/lib en su caso. Manténgalo intacto. A lo sumo, puede agregar bibliotecas que quiera compartir entre todas las aplicaciones web, o incluso mejor, configurar el shared.loader en Tomcat/conf/catalina.properties para eso.

Elimine también las bibliotecas específicas del servidor de aplicaciones y específicas de las carpetas JDK/lib y JRE/lib , si las hubiera. He visto con demasiada frecuencia que algunos iniciadores mueven / copian las bibliotecas allí porque "de lo contrario no compila". Nunca debe copiar bibliotecas que no sean JRK / JRE allí. También es una receta para problemas de portabilidad. Al compilar clases con javac , debe usar el argumento -cp para especificar las bibliotecas dependientes.

Actualización : en el caso de un IDE (parece que usa uno porque está hablando de "compilar ruta"), necesita asociar el proyecto web con un servidor de aplicaciones. En Eclipse, por ejemplo, tiene la opción de hacer eso durante la creación de un Proyecto web dinámico . Debe integrar la instancia del servidor en Eclipse antes de la creación del proyecto. Puede hacerlo a través de la vista Servers (suponiendo que está utilizando Eclipse para desarrolladores Java EE , de lo contrario, actualice). También puede cambiarlo luego a través de la entrada Servidores en las propiedades del proyecto. Elija uno que desee usar como el servidor "predeterminado" y luego sus bibliotecas se incluirán automágicamente en la ruta de compilación del proyecto. No hay absolutamente ninguna necesidad de copiarlos / moverlos a otro lugar. Consulte también ¿Cómo importo la API javax.servlet en mi proyecto Eclipse?