When a hosted JSP application starts failing after deployment, missing libraries are one of the most common causes. In a managed hosting environment, the application may compile successfully on your local machine, but still fail on the server because a required JAR is not included, is placed in the wrong folder, or is expected from a different classpath than the one used by Apache Tomcat. This is especially important for JSP, Servlet, and WAR deployments running through a hosting control panel such as Plesk, where the build output must be packaged correctly before upload.
On a Java hosting platform with a private JVM or Tomcat instance, such as a setup managed through a custom extension like My App Server, the server does not magically add third-party dependencies for your application. If your JSP pages, servlets, tag libraries, or helper classes rely on external libraries, those libraries must be packaged with the application or made available to the application server in the correct way. Otherwise, errors such as ClassNotFoundException, NoClassDefFoundError, JSP compilation failures, or missing tag handler classes may occur.
Why missing libraries break hosted JSP applications
A JSP application depends on more than just JSP files. In most real projects, JSP pages call Java helper classes, use tag libraries, access data through JDBC drivers, or rely on frameworks such as JSTL, Spring, JSON libraries, or file upload components. During deployment, Tomcat must be able to locate every class and resource that the application needs at runtime.
If a library is missing, the application may fail in several ways:
- The JSP page does not compile.
- The servlet or controller throws a runtime exception.
- The application starts, but certain pages return HTTP 500 errors.
- Framework components load partially, then fail when a specific class is referenced.
- Tag libraries or custom filters are not found by the container.
In hosted environments, this usually comes down to packaging and classpath scope. The build output must include the right JAR files in the right location for the way the application is deployed.
Typical symptoms of a missing library
Before changing your build, it helps to identify the exact error message. The type of error usually indicates whether the issue is a missing dependency, a conflict between versions, or a library placed in the wrong scope.
Common errors you may see
- java.lang.ClassNotFoundException - the JVM cannot load a class at runtime.
- java.lang.NoClassDefFoundError - a class was available during compilation, but not at runtime.
- JasperException during JSP compilation - often caused by a missing taglib or helper class.
- HTTP Status 500 on a JSP page - the page compiled incorrectly or a dependency is unavailable.
- SEVERE: Servlet.init() errors - a servlet or filter cannot start because a required class is missing.
- UnsupportedClassVersionError - not a missing library itself, but often confused with dependency problems in Java hosting.
In a Tomcat hosting environment, these messages usually appear in the application logs or in the service logs available from the hosting control panel.
How classpath works in hosted Tomcat and JSP deployments
Understanding the classpath is the key to solving missing library problems. Tomcat looks for classes and JAR files in specific places, and not every folder is treated the same way.
Application-level libraries
Most web applications should package third-party libraries inside the application itself, usually under WEB-INF/lib. Classes compiled from your own source code are usually placed in WEB-INF/classes.
This is the safest approach for shared hosting and private JVM environments because the application carries its own dependencies and does not rely on global server folders.
Server-level libraries
Tomcat also supports server-level libraries, which are available to all deployed applications. In a managed hosting setup, this is usually restricted or intentionally limited, because one app should not affect another. For this reason, the recommended approach is to bundle application-specific libraries inside the WAR file unless your hosting provider explicitly documents a shared server library path.
Build tool scopes
If you use Maven or Gradle, some dependencies are only present at compile time. If a library has provided scope or is excluded from the WAR output, the application may compile locally but fail on the server. This is a common reason for missing libraries in JSP hosting.
Most common reasons libraries go missing
Missing libraries are often caused by a build or packaging mistake rather than a server fault. Below are the most frequent causes in hosted JSP applications.
1. The JAR is not included in the WAR
The most common problem is simple: the dependency exists in the source project, but it was never copied into the final build output. If the JAR is not inside WEB-INF/lib, Tomcat cannot load it for that web application.
2. The library was placed in the wrong folder
Some developers upload JARs next to JSP files, in the root of the project, or in a custom folder that Tomcat does not scan. For a standard JSP application, runtime libraries should be placed according to the webapp structure. Files outside the correct locations are ignored.
3. The dependency is marked as compile-only or provided
If you use a build system, a library may be declared in a scope that excludes it from the package. That is fine for environments where the container supplies the library, but in hosted Tomcat it often means the JAR is missing at runtime.
4. There is a version mismatch
Sometimes a library is present, but the wrong version is deployed. The application may expect one API while the server contains another. This can happen with JSTL, logging frameworks, servlet APIs, or database drivers. A version mismatch can look like a missing class error even when a JAR is present.
5. The application uses a different Java version than the one used to build it
In a Java hosting environment, the selected JVM version matters. A library compiled for a newer Java version may not load on an older runtime. This is not the same as a missing dependency, but the symptoms can be similar.
6. Conflicting duplicate JARs
Two different versions of the same library may be deployed at once, causing unpredictable behavior. Tomcat might load the wrong one first, which can produce startup failures or strange JSP errors.
How to package JSP build output correctly
For hosted deployment, the best practice is to produce a clean WAR file or a properly structured web application folder. The build output should contain everything the application needs at runtime, except for libraries explicitly provided by the hosting environment.
Recommended folder structure
A typical JSP web application should resemble the following structure:
WEB-INF/WEB-INF/classes/for compiled application classesWEB-INF/lib/for external JAR dependenciesweb.xmlif your application uses deployment descriptors- JSP files and static assets outside
WEB-INFas needed
If a JAR is part of the application runtime, it should normally go into WEB-INF/lib. If it is only needed at compile time, check whether it is really safe to exclude it from deployment.
What should not be uploaded manually into random folders
- JAR files in the web root without a clear deployment reason.
- Classes compiled into source folders instead of
WEB-INF/classes. - Framework files copied only to your IDE project but not to the build output.
- Old libraries left over from a previous release.
In managed hosting, deployment should be predictable and repeatable. A clean build helps avoid classpath surprises after upload.
How to check whether a library is missing
If your hosted JSP application fails, use a structured approach instead of guessing. The following checks usually identify the problem quickly.
1. Read the application logs
Start with the Tomcat logs available in the control panel or the application logs section. Search for the first stack trace entry that mentions a missing class, missing package, or JSP compilation failure. The first error is often the real cause.
2. Verify the WAR contents
Download or inspect the deployed WAR and confirm that the required JAR exists in WEB-INF/lib. If the file is not there, the problem is in the build process, not the server.
3. Confirm the dependency scope
Check your Maven pom.xml or Gradle build file. If the library is marked as provided, test whether it should instead be packaged with the application.
4. Check for duplicate versions
Search for multiple JARs that provide the same package or class. Remove outdated copies from the build output and redeploy.
5. Test with a minimal JSP page
Create a simple JSP page that imports only one known class from the library. If that page fails, you know the issue is with the dependency itself rather than business logic.
Practical steps to fix missing libraries in a hosted JSP app
The exact fix depends on your build setup, but the following steps work well for most Tomcat hosting and JSP hosting cases.
Step 1: Identify the missing class or package
Use the error message to find the exact class name. For example, if the error mentions a class from JSTL or a JDBC driver, note the package name and version if available.
Step 2: Locate the dependency in your project
Check whether the JAR is part of your source repository, build system, or IDE project configuration. Confirm whether it is actually being copied into the final artifact.
Step 3: Put runtime libraries into the WAR
Make sure runtime dependencies are included in the deployment package. If you use Maven or Gradle, review the packaging rules so the JAR ends up in the final WEB-INF/lib directory.
Step 4: Remove stale copies
Delete old build output, clean the project, and redeploy from scratch. Old JARs can remain in the artifact after incremental builds and create conflicts.
Step 5: Match the Java version on the server
Confirm that the library and your compiled classes are compatible with the Java version selected in the hosting control panel. In My App Server, the installed Java version for the private JVM should match your application requirements.
Step 6: Redeploy and retest
After updating the build, redeploy the application and test the same page that failed before. If the error changes, continue following the stack trace until all missing dependencies are resolved.
Special notes for Plesk and managed Java hosting
In a hosting platform with Plesk-based Java management, the control panel usually helps with service control, deployment, and JVM selection, but it does not replace proper application packaging. A private Tomcat or JVM instance still depends on the files you upload.
With a managed extension such as My App Server, you can install and control a separate Apache Tomcat instance inside your hosting account. This gives you practical control over Java version selection, service management, and deployment of WAR or JSP applications. However, the responsibility for bundling application libraries remains with your project build.
This is especially relevant for small and medium applications where a private JVM is useful, but the app still needs to be self-contained. If your app depends on third-party JARs, include them in the build output and avoid assuming that the hosting platform will supply them automatically.
Example: why a JSP page compiles locally but fails on the server
Suppose a JSP page uses a helper class from a PDF generation library. In your IDE, the class is available because the library is on the project classpath. The page compiles and runs locally. After deployment to hosted Tomcat, the page throws ClassNotFoundException because the JAR was added as a compile dependency but not included in the WAR.
The fix is not on the server side. The correct solution is to adjust the build so the library is included in WEB-INF/lib. After redeploying, Tomcat can load the class and the JSP page works again.
How to avoid missing library issues in future releases
Once you fix the current problem, you can reduce the chance of recurrence by adopting a few practical release checks.
- Use a clean build before every deployment.
- Inspect the WAR file before uploading it.
- Keep application dependencies inside the project, not only in the IDE.
- Document which libraries are required at runtime.
- Remove unused or duplicate JAR files from the package.
- Test after every Java version change in the hosting panel.
- Keep JSP, servlet, and framework dependencies aligned with the target Tomcat version.
If your hosting environment allows selecting different Java or Tomcat versions, test the application after each change. A dependency that works on one JVM version may fail on another if it relies on newer bytecode or APIs.
Frequently asked questions
Why does my JSP work locally but not on hosted Tomcat?
Usually because your local environment includes libraries that were not packaged into the WAR. Your IDE may use a broader classpath than the hosted server.
Should all libraries be placed in WEB-INF/lib?
Most application-specific runtime libraries should be placed there. Only libraries explicitly provided by the server should be excluded from the WAR.
Can I upload JAR files directly into the application root?
That is usually not recommended. Tomcat expects runtime libraries in the standard web application structure, especially under WEB-INF/lib.
What does NoClassDefFoundError mean?
It usually means the class was available during compilation but could not be loaded at runtime. This often points to a missing JAR, wrong scope, or version conflict.
Does My App Server install libraries automatically?
No. My App Server provides control over Java hosting, Tomcat, Java version selection, and service management, but your application must still include its own runtime dependencies correctly.
Can a wrong Java version look like a missing library problem?
Yes. If a dependency or your compiled classes require a newer Java runtime than the server uses, the application may fail with errors that resemble missing class issues.
Conclusion
Missing libraries are one of the most frequent reasons a hosted JSP application breaks after deployment. In Tomcat hosting, especially in a managed Plesk-based Java hosting environment, the server will only load what is present in the correct build output and classpath locations. If a dependency is missing, misplaced, excluded by build scope, or incompatible with the selected Java version, the application may fail at startup or during JSP compilation.
The most reliable fix is to package the application cleanly, keep runtime JARs in WEB-INF/lib, verify the WAR contents before deployment, and check logs for the first real error. With a private JVM and Tomcat instance managed through a hosting control panel, this approach gives you predictable deployment for JSP, servlet, and WAR-based applications without unnecessary server-side complexity.