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.

Check your lib/maven jar structure.

When you are compiling classes which are importing something from javax.servlet package, you need to have that dependency on your class path.

For example when you have public class FooServlet extends HttpServlet, then the Java compiler needs to be able to get javax.servlet.http.HttpServlet to check whether the parent is not final, whether you are implementing all abstract methods, etc.

Thank you for your quick reply. Things are bit more complicated, I'll go more into the details:

Our .ear application uses the OSLC4J library in version 2.1.0 which has this dependency:

<dependency>

<groupId>org.glassfish</groupId>

<artifactId>javax.servlet</artifactId>

<version>3.1-b33</version>

<scope>provided</scope>

</dependency>

This library consist of several files some of which we just adapted to our needs - we included the library source code into our project and removed the library jars from our build dependencies. The core OSLC4J library is taken as-is. When some class in the library accesses the HttpServletRequest injected via the @Context annoation the exception seen above is thrown. I just added this class's source code to our project and the exception is no longer thrown.

What exactly is the reason for the ClassNotFoundException in the first case and how do we solve this issue in a proper way?