When a hosted JSP application starts in Tomcat but fails with ClassNotFoundException, NoClassDefFoundError or a similar startup error, the usual cause is a missing library in the build output. In a managed hosting environment, this often happens when the application runs correctly on a developer machine, but the uploaded WAR package does not contain every required dependency. For JSP hosting and servlet hosting, the deployment must include all runtime libraries that are not already provided by the Java platform or the application server.
In a Plesk-based Java hosting setup such as My App Server, this is especially important because the application is deployed as a packaged artifact to a private JVM or a Tomcat instance. If the build is incomplete, Tomcat may load the web application, but a JSP page, servlet, filter, listener, or custom tag library can fail as soon as it tries to use a class that is not inside the package or available on the server.
Why missing libraries break a JSP application
A JSP application usually depends on several types of classes:
- your own application classes
- framework classes such as Spring, Hibernate, or logging libraries
- container-provided APIs such as Servlet and JSP APIs
- third-party libraries used by controllers, tags, utilities, or business logic
During development, IDEs often resolve these dependencies automatically from the local project setup. On a hosting platform, however, only what is packaged and deployed is available at runtime. If a JAR file is missing from the final build output, the application may:
- fail during startup
- deploy but show errors only when a page is accessed
- compile locally but fail on the hosted Tomcat environment
- work on one Java version and fail on another because a dependency is not included properly
For UK JSP hosting customers, this is a common deployment issue because the problem is not the hosting account itself, but the application packaging.
Typical error messages caused by missing libraries
Missing dependencies usually appear in one of these forms:
- java.lang.ClassNotFoundException - the class could not be located on the runtime classpath
- java.lang.NoClassDefFoundError - the class was available at compile time, but not at runtime
- javax.servlet.ServletException with a nested class loading error
- JSP compilation failed when a tag library or helper class is missing
- 500 Internal Server Error after a page tries to call a missing dependency
The exact class name in the error message is usually the best clue. If the missing class belongs to your own application, the build output is incomplete. If the missing class belongs to a third-party library, the dependency was likely not included in the WAR or was marked with the wrong scope.
How Tomcat and Plesk handle application libraries
In a Java hosting platform with Tomcat and Plesk control, your application is typically deployed as a WAR file or from an exploded web application directory. The container loads classes from several places:
WEB-INF/classesfor your compiled application classesWEB-INF/libfor bundled JAR dependencies- Tomcat and JVM shared libraries, when configured by the platform
For most JSP hosting and servlet hosting projects, the safest approach is to package application-specific dependencies inside WEB-INF/lib. That way, the hosted application has everything it needs, independent of the build machine.
On a managed hosting account with My App Server, this is usually the most reliable deployment model because it reduces surprises between local testing and the live environment.
Common reasons a dependency is missing from the build output
Dependency scope is wrong
In Maven or Gradle, a library can be marked as provided, test, or another scope that does not package it into the final artifact. This is correct for some APIs, but not for runtime dependencies. A common mistake is to mark a library as provided even though Tomcat does not supply it.
The JAR is only in the IDE, not in the build tool
Some projects work in Eclipse, IntelliJ IDEA, or NetBeans because the IDE adds the library to the classpath. If the dependency is not declared in Maven, Gradle, Ant, or the project build file, it may disappear when the WAR is generated.
Custom build scripts do not copy the libraries
If you use Ant or a manual packaging process, the script may compile the classes but forget to copy the JAR files into WEB-INF/lib. This is one of the most frequent causes of runtime errors in hosted JSP applications.
Using server-level libraries by mistake
Some applications run locally only because the developer put JAR files into a local Tomcat lib folder. That approach does not travel with the application package. In hosting, the application should not rely on hidden local server files unless the platform explicitly provides them.
Version mismatch
A library may be present, but not the correct version. The class exists, but an expected method does not. In that case the error may be NoSuchMethodError or UnsupportedClassVersionError instead of a basic missing class error.
How to check whether the build output is complete
Before uploading a JSP application to a Tomcat hosting account, verify the contents of the WAR file or deployment directory.
- Open the WAR archive and check
WEB-INF/lib. - Confirm that every third-party runtime dependency is present as a JAR.
- Check
WEB-INF/classesfor your compiled application classes. - Make sure the application does not depend on local files outside the package.
- Review the build tool configuration to confirm the final artifact includes runtime libraries.
If the application works from the IDE but fails after deployment, compare the local runtime classpath with the packaged WAR. Differences usually reveal the problem quickly.
Best practice for WAR packaging in hosted JSP environments
For a hosted JSP application, the deployment package should be self-contained, except for APIs that the container already provides. A good WAR file usually includes:
- all application classes
- all third-party runtime libraries
- JSP tag libraries required by the app
- resource files such as configuration XML, properties files, and templates
It should not include:
- duplicate servlet API JARs if the container already supplies them
- test libraries
- local development-only files
- large unused dependencies that are not needed at runtime
This balance matters because a hosted environment is simpler to troubleshoot when the package is clean and complete.
Step-by-step: fix missing library errors
1. Identify the exact missing class
Read the full stack trace in the Tomcat logs or the application error page. The first missing class name is usually the one you need to track down. If the class belongs to a known library, check whether that library is in the package.
2. Confirm the dependency is declared in the build tool
For Maven, check pom.xml. For Gradle, check build.gradle. For Ant, review the copy and package steps. The dependency must be part of the runtime artifact, not just the compile classpath.
3. Rebuild the application from scratch
Use a clean build to avoid stale classes or incomplete output. Delete old target or build folders, then generate the WAR again. This helps ensure you are testing the exact package that will be uploaded to the hosting platform.
4. Inspect the WAR file manually
Do not assume the build was correct. Open the archive and verify that the JAR is really inside WEB-INF/lib. If the library is missing there, Tomcat cannot load it.
5. Check for duplicate or conflicting JARs
If the library is present but the app still fails, there may be conflicting versions. Remove duplicates from the application package and keep only one version of each library. Conflicts can be just as harmful as missing files.
6. Redeploy and test the application
After updating the package, upload it again through the control panel, redeploy it in Plesk, and test the pages that previously failed. If the app is on My App Server, restart the service if needed so the container loads the updated package cleanly.
How this works in My App Server and Plesk
With ITA's Java hosting through My App Server, you can manage Java and Tomcat inside a shared hosting account with a separate JVM for the application. That gives you practical control over deployment while keeping the platform simple to operate.
If a JSP application fails because of missing libraries, the usual workflow is:
- check the application logs in Plesk
- verify the WAR contents
- correct the build configuration
- upload the rebuilt package
- restart the service if necessary
This model is well suited for small and medium Java applications, WAR deployments, JSP sites, and servlet-based projects that need a private JVM without the complexity of a large enterprise application server setup.
Examples of common dependency mistakes
Example 1: logging library missing
An application uses Log4j, SLF4J, or another logging framework locally. The code compiles, but the hosted Tomcat environment throws an error because the logging JAR was not included in the WAR.
Example 2: database driver not packaged
The application connects to MySQL, PostgreSQL, or another database. The driver was installed locally for development but not added as a runtime dependency. The application starts, but fails when a database connection is attempted.
Example 3: custom tag library not available
A JSP page uses custom tags from a separate library. The tag classes are missing from WEB-INF/lib, so the JSP compiler cannot resolve the tag handler classes.
Example 4: framework JAR excluded by build scope
A Spring or utility dependency is marked with a scope that prevents packaging. The app deploys, but a controller or helper class fails at runtime because the framework class is not available.
How to avoid the issue in future builds
- declare all runtime dependencies in the build tool
- use one repeatable build process for every release
- test the WAR file, not only the IDE project
- avoid depending on local server libraries
- check the final archive before uploading it to hosting
- keep versions aligned across compile and runtime environments
If multiple developers work on the same JSP application, it also helps to document which libraries are required and where they must appear in the package. This reduces deployment issues when the project moves between local machines and the hosted environment.
When the problem is not a missing library
Not every class loading error is caused by an absent JAR. Similar symptoms can come from:
- Java version incompatibility
- corrupted deployment files
- wrong package structure inside the WAR
- permission issues preventing Tomcat from reading files
- conflicting copies of the same class in different locations
If the library is definitely present, check the Java version selected in the hosting control panel and compare it with the version used to compile the application. A class compiled for a newer Java release may not run on an older JVM.
Checklist before uploading a JSP application
- WAR contains
WEB-INF/classes - WAR contains all runtime JAR files in
WEB-INF/lib - no test-only dependencies are included
- no local-only server libraries are required
- Java version matches the application build
- application starts cleanly in a local Tomcat test
- logs show no class loading errors
FAQ
Why does my JSP application work locally but fail on the hosting account?
Usually because the local environment has libraries that are not included in the WAR. In hosting, only packaged runtime dependencies are available unless the platform provides them separately.
Should I place JAR files in Tomcat’s global lib folder?
Only if you specifically want a shared library for multiple applications and your hosting setup allows it. For most JSP applications, packaging the JARs inside the WAR is safer and easier to manage.
Can I rely on the servlet API JAR being included in my WAR?
No. The servlet and JSP APIs are normally provided by Tomcat. Including the wrong API JAR in your application can cause conflicts.
What is the fastest way to find the missing library?
Check the full error stack trace, identify the missing class, and search your build output for the JAR that contains it. Then verify the dependency scope in your build file.
Why do I get NoClassDefFoundError instead of ClassNotFoundException?
Both can point to packaging problems. NoClassDefFoundError often means the class existed during compilation but is not reachable at runtime, either because the JAR is missing or because another dependency failed earlier in the load process.
Can My App Server help me manage Tomcat for a JSP application?
Yes. In a Plesk-based hosting setup, My App Server provides practical control over Java hosting, Tomcat deployment, service management, and Java version selection, which makes it easier to test and redeploy WAR-based JSP applications.
Conclusion
Missing libraries are one of the most common reasons a hosted JSP application fails after deployment. In a Tomcat hosting environment, the key rule is simple: if the application needs a library at runtime, that library must be available in the deployed package or provided by the container. For most applications, the cleanest approach is to package all runtime dependencies inside the WAR, verify the contents before upload, and test the deployment using the same Java version and container setup as the live hosting account.
With a managed Java hosting platform such as My App Server in Plesk, this process is straightforward: build the WAR correctly, confirm the libraries are present, deploy, and check the logs if anything fails. When the build output is complete, JSP and servlet applications usually run reliably without extra server-side changes.