java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletRequest

Question

I'm developing a servlet that receives a multipart request with content of multiple files, and I'm using apache commons file upload libraries.

When I call parseRequest(request); method servlet throws following exception:

GRAVE: Servlet.service() for servlet DiffOntology threw exception
java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletRequest
    at org.apache.commons.fileupload.servlet.ServletRequestContext.getContentType(ServletRequestContext.java:73)
    at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:882)
    at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
    at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:349)
    at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
    at DiffOntology.doPost(DiffOntology.java:38)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:738)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Thread.java:619)

I put all libraries in WEB-INF/lib.

EDIT:

servlet-api.jar is in the correct directory (tomcat/lib) and all others libraries are in WEB-INF/lib

I think maybe the problem could be the following: I'm developing this web project in Eclipse, and I imported file uploads libraries in the classpath.

How it doesn't work?

I'm desperate!!

Yorgen

Answer 1

This can happen when you've placed server-specific libraries in the webapp's /WEB-INF/lib or probably JRE/lib. Big chance that you copied Tomcat's /lib/servlet-api.jar into there. You shouldn't do that. This would only lead to collisions in the classpath which leads to this kind of errors and it will make your webapp unportable (i.e. it is tied to run on Tomcat only, you can't run it at another servers like Glassfish, JBoss AS, Websphere, etc). You should keep the server-specific libraries at their default location. Cleanup the /WEB-INF/lib from any server-specific libraries and cleanup JRE/lib from any 3rd party libraries.

You probably copied server-specific libraries there because you wasn't able to compile your servlets. Copying the libraries in /WEB-INF/lib is the wrong solution. You should basically just specify those libraries in the compiletime classpath. Since you're using Eclipse, this can be done easily: first add Tomcat in Servers view, then associate your webapp project with the integrated Tomcat instance. This way Eclipse will automatically add the server-specific libraries to the project's buildpath. On a brand new web project you can choose the server during project creation wizard. On existing web projects, you can modify it in Targeted Runtimes section in project's properties.

See also:

• How do I import the javax.servlet API in my Eclipse project?

Jakie

Placing servlet-api.jar in WEB-INF/lib would have no effect, since Tomcat delegates to the parent class loader for javax.servlet. Even if it didn't, the exception would be ClassCastException, not NoClassDefFoundError. – Cockspur

@bkail: Fair point which of course depends on classloading policies (for which is true that this doesn't apply on a default Tomcat config), but was that worth a downvote? How about the remnant of the answer? That's a bit too harsh. Point is still clear: do not pollute webapp/JRE libs with server-specific libraries. – Jakie

Sorry, I didn't mean to be harsh. The site FAQ says to downvote misinformation, and it is misinformation to say that placement of servlet-api.jar (or even "server-specific libraries") in WEB-INF/lib or JRE/lib could be the cause of the NoClassDefFoundError, so your first paragraph would only cause the user to spend time investigating the wrong thing. The rest of your answer is good, so fix that and of course I'll remove the downvote. – Cockspur

Thanks @Jakie , I had the same problem , but when I moved the libs from JRE/lib to other path, it worked without any exception. – Jamestown

Answer 2

You must have incorrectly copied commons-fileupload.jar to JRE/lib/ext, JRE/lib/endorsed, or otherwise placed it on a classpath that does not have visibility to the servlet APIs. Start the JVM with -verbose:class, which will print which classpath loaded the ServletFileUpload class. If the class is loaded from anywhere other than WEB-INF/lib, you'll need to remove it.

Cockspur

Huh? Why are you suggesting to place libraries in JRE/lib? This may work, but this makes your webapp unportable. This is certainly not the right way. This is more a hack/workaround. – Jakie

"Huh?" indeed :-). My answer must have been worded poorly, so I've updated to add the word "incorrectly". I was not saying he should put jars in JRE/lib, I was saying that in order to get NoClassDefFoundError, that's what he must have already done. He needs to use only WEB-INF/lib for commons-fileupload.jar, and he needs to delete any jars he added to other classpaths. – Cockspur

Answer 3

Old thread but can still help someone. I saw that i had a javax-servlet jar in the dependency included with a test scope. I made it to provided scope. Check the dependency graph if you are using Eclipse +Maven.

Aculeate

In IntelliJ, this would be in Project Settings -> Modules -> Dependencies – Phillada

Answer 4

I got that error when mistakenly using a Tomcat 10 Docker image for my WAR file build for Tomcat 9. I used a Docker image without a specific tag which came with the latest Tomcat (in my case 10) (tomcat:jdk17-temurin).

Using Tomcat 10 would need adjustments as the Tomcat 10 doc states:

There is a significant breaking change between Tomcat 9.0.x and Tomcat 10.0.x. The Java package used by the specification APIs has changed from javax... to jakarta.... It will be necessary to recompile web applications against the new APIs.

In my case I simply resolved that error by specifiyed an image with a specific Tomcat version (e.g. tomcat:9.0.56-jdk17-temurin).

Jiggered

Alternative one might replace commons-fileupload with the almost identical features from Servlet 3.0, like in this question. – Charwoman

Answer 5

Remove any servlet-api.jar or the upload helping jar commons from JRE/lib or JRE/lib/ext. This helped me fix the problem.

Neurotic

Answer 6

I had the same problem. The reason why I had this problem is that since I am using jakarta-servlet-api I assumed that the class I need is in a jakarta package. However, when I extracted the api I saw that the package is called javax, so I imported javax.servlet.http.HttpServlet instead and it worked fine.

Girovard

Answer 7

On Gentoo Linux, using Tomcat 9, for the purposes of developing Java EE apps on Eclipse, I would get this error message when attempting to launch the server from the Servers window on Eclipse's Java EE perspective. I tried manually adding /usr/share/tomcat-servlet-api-4.0/lib/servlet-api.jar to my project's classpath, didn't work. I tried manually adding that file to the CLASSPATH variable on /usr/share/tomcat-9/package.env, didn't work.

After many unsuccessful attempts to fix that, my intuition told me that maybe the Portage distribution was meant to run as a standalone daemon managed from shell rather than from Eclipse, and that maybe, for development purposes, I had to install a plain vanilla instance of Tomcat. So I went to manually download Tomcat 9 from the official web page and manually extracted it; I used /opt/apache/tomcat/tomcat9, but in theory any directory should do. I did that, and Tomcat finally started successfully.

tl;dr: if you're developing Java EE apps on Gentoo, don't use the Portage distribution, download and install it manually from the official web site instead.

Alpenglow

Answer 8

check the version of your Tomcat, if you are using 10.1.24 then you have to change the dependency of javax 4.0 to jakarta 6.0

instead of

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

use

 <dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>6.0.0</version>
    <scope>provided</scope>
    </dependency>

Eam