Error :
Solutions :
This error can be resolved in the following three cases:
1. Clean project and server
Or:
2. Remove .snap file from this directory
<workspace-directory>\.metadata\.plugins\org.eclipse.core.resources
Or
3. Remove temp file from this directory
<workspace-directory>\.metadata\.plugins\org.eclipse.wst.server.core
In my case it was another issue :
Les servlets nommés [serv1] et [controller.serv1] sont tous deux associés au même modèle d'URL
[/serv1],
This means that two servlets (likely one named serv1 and another named controller.serv1) are
both trying to handle requests for the /serv1 URL path, which is not allowed.
Error:
The import jakarta cannot be resolved
Solution:
Convert project to Maven project
Add Jakarta dependencies in pom.xml:
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>5.0.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
Error :
ClassNotFoundException
Solution :
Add driver jar to classpath
Add it to the Deployment Assembly
Deployment Assembly - -> Add --> Java Build Path Entries
Why Deployment Assembly Matters in Web Applications
1. Web Applications Have a Specific Structure:
o Web applications deployed on servers like Tomcat follow a specific directory
structure (e.g., WEB-INF/lib for libraries).
o Simply adding a JAR to the classpath makes it available for compilation in
Eclipse, but it doesn’t ensure that the JAR is placed in the WEB-INF/lib folder
of the deployed WAR or web application directory. Without being in WEB-
INF/lib, Tomcat (or any other servlet container) won’t be able to load it.
2. Deployment Assembly Controls What Gets Deployed:
o The Deployment Assembly in Eclipse tells the IDE which resources and
libraries should be included when the application is deployed to a server.
o By default, the deployment configuration doesn’t always include external
libraries in the deployment, even if they’re in the build path.
o Adding a JAR to the Deployment Assembly explicitly includes it in the
deployable package, ensuring that the JAR is copied to the WEB-INF/lib
directory.
3. Class Loading in Tomcat and Web Applications:
o Tomcat (and other application servers) have a different class loading hierarchy
than a simple Java application.
o For Tomcat to recognize a JAR, it must be in the specific location where
Tomcat expects libraries for the application (i.e., WEB-INF/lib).
o When a JAR is only on the classpath, Eclipse knows about it, but Tomcat
might not, unless it’s deployed in the correct structure (inside WEB-INF/lib).
4. Avoiding ClassNotFoundException at Runtime:
o The ClassNotFoundException happens because Tomcat’s class loader cannot
find the com.mysql.cj.jdbc.Driver class at runtime.
o Adding the JAR to the Deployment Assembly ensures the JAR is available to
Tomcat in WEB-INF/lib, so it can find and load the class.
In Summary
ClassPath: Makes the JAR available for compilation in Eclipse.
Deployment Assembly: Ensures the JAR is included in the actual deployed package
to Tomcat’s runtime environment.
When You Could Skip Deployment Assembly
If you’re working on a standalone Java application (not a web application) or if you place
the JAR directly in Tomcat’s lib directory (making it globally available to all applications on
that server), you might not need to use Deployment Assembly. But for a web application that
relies on libraries, setting up Deployment Assembly properly is a best practice and helps
avoid runtime issues.
Error :
Solution:
Change Dynamic web module version from 6.0 to 5.0.
