When a hosted Java application starts throwing ClassNotFoundException, NoClassDefFoundError, or fails during startup after deployment, the cause is often not the code itself but a missing library in the build output. In a managed hosting environment with Java hosting, Tomcat hosting, or a private JVM managed through a control panel such as Plesk, this usually means the application was packaged without all required JAR files or with an incorrect deployment structure.
For hosted applications deployed as WAR files, the build output must include every runtime dependency that is not already provided by the container. If a library is present in your local development environment but not included in the final package, the app may work on your machine and fail after upload. This is especially common with Apache Tomcat, where the web application runs inside a servlet container and expects dependencies to be placed in the correct location.
Why missing libraries cause problems on hosted Java applications
Java applications depend on classes that are loaded at runtime. When the JVM or Tomcat cannot find a required class, the application may fail in several ways:
- ClassNotFoundException when a class cannot be loaded dynamically.
- NoClassDefFoundError when a class was available during compilation but is missing at runtime.
- Servlet initialization errors when a dependency required by a controller, filter, listener, or framework is not available.
- Startup failures when a framework such as Spring, Hibernate, or a logging library cannot initialize.
- 500 Internal Server Error when the app launches but fails on the first request.
In hosting setups where you manage your own Tomcat instance through My App Server, the issue is often related to the contents of the uploaded package rather than the platform itself. The hosting environment provides the runtime, but your application must still include the libraries it needs.
How build output affects deployment success
The build output is the final artifact produced by your build tool, such as Maven, Gradle, or Ant. In a Java hosting environment, this is usually a WAR file for web applications or a JAR for standalone applications. If the output is incomplete, the application may deploy successfully in Plesk but fail during execution.
Common packaging mistakes include:
- Dependencies marked as
providedeven though the runtime does not supply them. - Libraries used in development but excluded from the final WAR.
- Modules copied into the wrong folder inside the archive.
- Version conflicts between libraries bundled in the app and libraries loaded by Tomcat.
- Missing transitive dependencies that were not included by the build tool.
For hosted Tomcat deployments, this usually means the application works locally with an IDE run configuration but fails after upload to the server because the local classpath is not the same as the production classpath.
Typical signs that a library is missing
If you suspect a packaging problem, check for these symptoms:
- The application deploys but the page returns an error immediately.
- The Tomcat log shows a class loading error during application startup.
- One feature works while another fails, often after clicking a specific page or action.
- The app works on one version of Java but not on another.
- The same code runs in your IDE but fails in the hosted environment.
These errors often appear in the service logs available through the hosting control panel. In a Plesk-based Java hosting setup, review the application logs and Tomcat logs first, because they usually point to the exact missing class or package.
Where libraries should go in a WAR file
For most hosted Java web applications, the correct location for third-party libraries is the WEB-INF/lib directory inside the WAR file. Classes compiled from your own source code typically belong in WEB-INF/classes.
Correct layout example
WEB-INF/classes— compiled application classesWEB-INF/lib— external JAR dependenciesWEB-INF/web.xml— deployment descriptor when used
If a library is placed outside the WAR structure, Tomcat may not load it for the web application. Likewise, if the build tool excludes a required JAR from the package, the app may start but fail at runtime.
How this works in Plesk and My App Server
With ITA’s Java hosting approach and the My App Server extension, you can manage your own Tomcat instance and JVM inside your hosting account. This gives you practical control over the Java runtime, service status, and deployment process without needing a full dedicated Java platform.
That control is useful, but the application still must be built correctly. The hosting platform can provide:
- a selected Java version,
- a Tomcat service or custom app server,
- deploy and restart controls,
- logs for troubleshooting,
- an isolated JVM for your site or app.
However, the platform cannot compensate for missing build-time dependencies that were never included in the uploaded package. If a class is not in the build output, Tomcat cannot magically find it unless it is available from a shared server library, which is not the normal assumption for portable Java deployment.
Step-by-step: how to fix missing library errors
1. Read the exact error message
Start with the first missing class or package named in the log. The first error is usually the root cause. Later errors may only be a consequence of the first one.
Look for messages such as:
java.lang.ClassNotFoundExceptionjava.lang.NoClassDefFoundErrorFailed to load classSEVERE: Error starting childContext initialization failed
2. Check whether the dependency is included in the WAR
Open the WAR archive and confirm the library is present under WEB-INF/lib. If the JAR is missing, the build output is incomplete.
If you use Maven or Gradle, inspect the build configuration to confirm the dependency scope. A dependency marked as provided, test, or otherwise excluded will not be bundled unless you configure packaging explicitly.
3. Verify the dependency scope
Some libraries should be bundled with the application, while others should not. For example, servlet API libraries are often provided by Tomcat and should not be packaged into the WAR. By contrast, application-specific libraries such as JSON parsers, HTTP clients, or ORM libraries usually must be included.
Check for accidental use of:
providedscope for runtime-needed libraries,- incorrect exclusions in Maven or Gradle,
- manual copying of only part of a library tree,
- dependency conflicts from multiple versions.
4. Rebuild from a clean state
Sometimes old build artifacts remain in the output folder and hide packaging issues. Clean the project and build again so the artifact reflects the current dependency list.
Useful checks include:
- delete stale
targetorbuilddirectories, - rebuild the WAR from scratch,
- re-upload the newly generated package,
- restart the Tomcat service after deployment.
5. Test with the same Java version used on hosting
A library may fail not because it is missing, but because it is incompatible with the Java version in use. If your hosting account uses a different Java release than your local machine, ensure the application is tested against the same runtime.
This is especially important when deploying to a managed Java hosting setup where you can select between available Java versions. A library compiled for a newer JVM may fail on an older one, and some older libraries may break on newer versions.
6. Check Tomcat logs and application logs
Logs usually identify the missing class. In a Plesk-managed environment, review the service logs and application-specific logs through the control panel. If you run a private JVM with Tomcat through My App Server, check the service output after each restart and deployment.
Useful log clues include:
- the exact class name that could not be found,
- the library or framework that failed to initialize,
- the path where the deployment failed,
- additional exceptions caused by the first missing dependency.
Common build tool mistakes
Maven packaging issues
Maven is a common source of missing library problems when the dependency scope is set incorrectly. A library needed at runtime should usually have a scope that includes deployment packaging. If it is marked provided, it will not be included in the WAR.
Also check for transitive dependencies. A framework may rely on several supporting JARs that are not obvious from the top-level dependency list.
Gradle packaging issues
With Gradle, the dependency configuration matters. Dependencies placed only in test configurations or excluded from the final artifact will not be available in production. If you create a custom WAR, confirm that all runtime dependencies are assembled properly.
Manual build issues
When applications are built manually or exported from an IDE, it is easy to miss one or more JAR files. This often happens when the developer copies the compiled classes but forgets the library directory.
For hosted deployment, manual packaging is more error-prone than using a repeatable build process, so always verify the final archive before uploading it.
How to package a hosted Java application correctly
To reduce deployment issues in a hosting environment, use a simple and repeatable build process.
- Keep all runtime dependencies declared in the build file.
- Generate a WAR with the correct directory structure.
- Exclude only libraries that Tomcat already provides.
- Test the artifact locally before uploading it.
- Check the final WAR contents before deployment.
- Use the same Java version for local testing and hosting when possible.
If your application uses JSP pages, servlets, or a framework that depends on external JARs, confirm that every required library is inside the final package. This is particularly important for small and medium-sized applications hosted on a shared account with a private JVM or Tomcat instance.
When the library is on the server but still not found
Sometimes the library exists somewhere on the server, but the application still cannot see it. This usually happens when the JAR is placed in the wrong classpath location. In Tomcat, library visibility depends on where the file is placed:
- libraries inside
WEB-INF/libare available to the web application, - libraries in the server-wide Tomcat
libdirectory are shared by all applications and should be used carefully, - application classes in
WEB-INF/classesare available only to that app.
In a managed hosting setting, avoid assuming that a library copied into a general server location will automatically be available to your app. The safest approach is to bundle application-specific dependencies in the WAR unless the documentation for your setup says otherwise.
Best practices for Tomcat hosting and Java build output
- Keep the build reproducible so the same artifact is produced every time.
- Do not rely on your IDE’s local classpath.
- Check dependency scopes before deployment.
- Use logs to confirm the exact missing class.
- After changing libraries, redeploy and restart the service.
- Match the application package to the Tomcat and Java version in use.
- Prefer WAR-based deployment for web apps that run under Tomcat.
These practices fit well with a hosting control panel workflow because they reduce trial-and-error and make it easier to diagnose issues through logs and service controls.
FAQ
Why does my Java app work locally but fail on the hosted server?
Because your local environment may include libraries that were not packaged into the WAR. The hosted server only sees the files included in the deployment artifact and the libraries provided by the runtime.
What is the most common sign of a missing library in Tomcat?
The most common signs are ClassNotFoundException or NoClassDefFoundError in the logs during startup or when a specific feature is used.
Should I copy every JAR into Tomcat’s global lib folder?
No. For hosted web applications, it is usually better to place application-specific libraries inside WEB-INF/lib. Use shared server libraries only when you clearly understand the impact on all hosted applications.
Can Plesk detect missing libraries automatically?
No hosting panel can fully infer whether your build output is complete. Plesk and My App Server can help you deploy, restart, and inspect logs, but the application package still must include the correct dependencies.
How do I know if a dependency should be bundled?
If your application needs it at runtime and Tomcat does not provide it by default, it should usually be bundled in the WAR. Servlet API and similar container-provided libraries are common exceptions.
What should I check first after upload?
Check the deployment logs and the first startup error. Then inspect the WAR contents to confirm that the missing class belongs to a JAR inside WEB-INF/lib.
Conclusion
Missing libraries are one of the most common reasons a hosted Java application fails after deployment. In a Java hosting setup with Tomcat and a control panel such as Plesk, the issue is usually caused by an incomplete build output, incorrect dependency scope, or a packaging structure that does not match the runtime expectations.
The fastest way to resolve the problem is to read the first error in the logs, verify the WAR contents, check the build configuration, and rebuild from a clean state. When your application is packaged correctly, deploying to a hosted Tomcat or private JVM environment becomes much more predictable, and your JSP, servlet, or WAR-based application can run as intended.