When a hosted Tomcat application starts but immediately fails with ClassNotFoundException, NoClassDefFoundError or Unable to load class, the cause is often simple: one or more libraries were not packaged with the application, were uploaded to the wrong location, or do not match the Java/Tomcat version used by the hosting environment. In a managed hosting setup with Plesk and a private JVM, this is usually a deployment issue rather than a problem with Tomcat itself.
On a Java hosting platform such as My App Server, your application may run inside its own Tomcat instance and JVM, which gives you control over the runtime version and deployment structure. That also means the application must contain everything it needs at build time, unless the library is intentionally provided by the container. If a dependency is missing from the WAR file, the app may work locally and still fail on the hosted server.
What “missing libraries” means in Tomcat hosting
In Java web applications, libraries are the JAR files that provide framework classes, database drivers, logging components, JSON parsers, and other runtime dependencies. A hosted Tomcat application typically expects these dependencies to be included in the application package, usually inside WEB-INF/lib of the WAR file.
A library problem can appear in several ways:
- The JAR was used during development but not included in the final build output.
- The dependency is in the wrong folder and Tomcat cannot see it.
- The application was built for a different Java version than the one selected in Plesk.
- Two versions of the same library conflict with each other.
- The app depends on a server-level JAR that is not available in the hosted environment.
In a shared hosting or managed Tomcat setup, these issues are common when the build process is not aligned with the deployment structure.
Typical error messages caused by missing libraries
Before changing anything, check the exact error in the application log. Missing library problems often produce one of the following messages:
java.lang.ClassNotFoundExceptionjava.lang.NoClassDefFoundErrorjava.lang.UnsupportedClassVersionErrorjava.lang.NoSuchMethodErrorjava.lang.NoSuchFieldErrorUnable to load classSEVERE: Error listenerStartFailed to instantiate servlet
These errors do not always mean the code is wrong. Very often, they mean the build output is incomplete or the wrong dependency version is being deployed.
Why this happens more often after deployment
A Java project can appear to work perfectly in an IDE because the IDE automatically resolves classpath dependencies. During local development, your build tool, test runner, and IDE may all have access to libraries that are not actually packaged into the WAR.
In hosted Tomcat environments, only the runtime files you upload are available. That makes deployment stricter. If a library is missing from the WAR, Tomcat cannot “guess” it from your local machine or development workspace.
Common reasons include:
- The dependency scope is set to
providedwhen it should be bundled. - The WAR packaging step was skipped or failed.
- The library was added to the project, but not to the final artifact.
- The application depends on a system library that exists on one server but not in your hosting account.
- The selected Java version in My App Server does not match the compiled bytecode.
Check whether the library should be bundled or provided by Tomcat
Not every dependency should be packaged inside the application. Some APIs are provided by the application server or the servlet container. For example, Servlet API classes are normally provided by Tomcat and should not be bundled in the WAR when the project is configured correctly.
However, most application-specific libraries should be included in the deployment package. This usually applies to:
- Spring and related framework JARs
- Database drivers such as MySQL, PostgreSQL, or MariaDB connectors
- JSON libraries
- Apache Commons components
- Validation and utility libraries
- Custom internal JAR files used by the application
If you are unsure, check the dependency scope in your build tool and confirm whether Tomcat is expected to provide the class.
How to verify your WAR file contains the needed libraries
The quickest way to diagnose the problem is to inspect the WAR file before uploading it to Plesk.
What to look for inside the WAR
WEB-INF/libcontains the dependency JARsWEB-INF/classescontains your compiled application classes- The expected servlet configuration files are present
- No old or duplicate JAR versions are included accidentally
If the required JAR is missing from WEB-INF/lib, Tomcat will not load it unless you place it somewhere else that the classloader can reach. In most hosting setups, keeping dependencies inside the WAR is the safest approach.
Practical check with a build tool
If you use Maven, Gradle, or another build tool, review the final package output rather than only the project tree. It is common to have a dependency declared correctly, but excluded from the final artifact because of packaging configuration, scope, or plugin settings.
Make sure that:
- the dependency is not marked as test-only
- the dependency is not excluded from the WAR plugin
- the shading or assembly task is not omitting transitive JARs
- the build output is the same file you upload to the hosting control panel
Where libraries must be placed in a hosted Tomcat application
For standard WAR deployment, Tomcat expects application libraries under WEB-INF/lib. Application classes belong in WEB-INF/classes. If you upload loose files manually, the structure still needs to follow the same rules.
In a managed hosting account with My App Server, the recommended approach is usually:
- Build a complete WAR file locally or in your CI system.
- Verify that all required JARs are included.
- Upload the WAR through Plesk or the Java application management interface.
- Restart the Tomcat service if needed.
- Check the application logs for any unresolved classes.
Do not place application libraries randomly in the document root. Tomcat will not treat them as part of the web application unless they are in the correct classpath location.
How Java version mismatches can look like missing libraries
Sometimes the root cause is not a missing JAR but an incompatible Java version. For example, an application compiled with a newer JDK may fail on an older runtime selected in the hosting panel. In logs, this can look similar to a library loading problem.
Common signs include:
UnsupportedClassVersionError- classes failing to load after a Java upgrade or downgrade
- libraries compiled for a newer bytecode level
- frameworks requiring a newer runtime than the one currently assigned to the app
With My App Server, you can choose from several ready-to-install Java and Tomcat versions or upload and configure a custom setup when needed. That flexibility is useful, but the application must still match the runtime you select.
How to troubleshoot the issue step by step
Use the following checklist to identify the missing dependency quickly.
1. Read the first error in the log
Do not rely only on the final exception shown in the browser. The first ClassNotFoundException or NoClassDefFoundError in the Tomcat log usually points to the real missing class.
2. Identify the class name
The log will usually mention the exact class or package that could not be found. Note the full name, for example:
org.apache.commons.lang3.StringUtilscom.mysql.cj.jdbc.Drivercom.fasterxml.jackson.databind.ObjectMapper
Once you know the class name, you can match it to a library artifact.
3. Check your build configuration
Review the dependency declaration in your project file. Confirm that the library is included in the runtime packaging, not only in test or compile-only scope.
4. Open the WAR and confirm the JAR exists
If the JAR is missing from WEB-INF/lib, fix the build, rebuild the WAR, and redeploy.
5. Remove duplicate or conflicting versions
Two versions of the same library can cause class loading problems that look like missing methods or broken classes. Keep only one compatible version where possible.
6. Confirm the selected Java and Tomcat version
In Plesk or the My App Server control interface, verify that the application is using the intended Java runtime and Tomcat version.
7. Restart the service and retest
After updating the application package or runtime selection, restart the service so Tomcat loads the new classpath cleanly.
How this works in My App Server and Plesk
In a hosting control panel environment, Java deployment is often handled through a dedicated extension rather than manual server administration. My App Server provides a practical way to manage a private JVM and Tomcat instance within a hosting account.
This is especially useful for:
- WAR-based Java web applications
- JSP sites
- Servlet applications
- small and medium Java hosting projects
- applications that need a chosen Java version
Because the service is managed through the panel, the deployment process should be kept clean and repeatable. The most reliable pattern is to build the application fully, include all required JAR files, and then deploy the finished artifact.
If you upload only part of the application or rely on local machine libraries, the hosted Tomcat instance will not have enough information to run it.
Best practices for packaging Java applications for hosted Tomcat
To avoid missing library issues, follow these packaging practices:
- Bundle all application-specific JAR files inside the WAR.
- Keep the build output consistent across local, test, and production environments.
- Use one dependency management method only, where possible.
- Do not depend on IDE-generated classpaths.
- Confirm the servlet and container-provided APIs are not duplicated in the WAR.
- Test the final WAR locally before upload.
- Document any custom library requirements for future deployments.
These steps reduce deployment surprises and make hosted Tomcat troubleshooting much easier.
Examples of common library-related failures
Missing database driver
An application connects to a MySQL or PostgreSQL database in development, but the production WAR does not include the JDBC driver. Tomcat starts, the app deploys, and then the first database request fails because the driver class is absent.
Missing JSON library
A controller or REST endpoint uses Jackson or Gson. The code compiles locally because the dependency exists in the IDE, but the deployed WAR does not include it, so class loading fails at runtime.
Conflicting framework versions
The app includes one version of a framework in WEB-INF/lib, while a different version was expected by the code. This can trigger NoSuchMethodError or initialization failures that look like broken deployment.
Java version too old
The application or a library was compiled with a newer Java version than the runtime selected in the hosting panel. Tomcat loads part of the application, then fails when it reaches the incompatible class.
When to ask the hosting provider for help
If the WAR file looks correct and the dependency is present, the next step is to confirm the hosting-side runtime setup. In a managed hosting environment, support can help verify whether the selected Java version, Tomcat instance, or application service needs a restart.
Contact support when:
- the error persists after rebuilding and redeploying the WAR
- the same application works locally but not on the hosted account
- you are unsure whether a class should be container-provided or bundled
- the application depends on a custom Tomcat or Java version
- logs show a runtime issue, but the package structure appears correct
When you ask for help, include the exact error message, the name of the missing class, the Tomcat version, the Java version, and whether the application was deployed as a WAR or as a custom setup.
FAQ
Why does my Java app work locally but fail on hosted Tomcat?
Local development tools often include libraries automatically through the IDE or build cache. Hosted Tomcat only sees the files in the deployed WAR and the runtime configured in the hosting panel.
Should all JAR files be uploaded separately to Tomcat?
No. In a standard WAR deployment, application libraries should normally be packaged inside WEB-INF/lib. Uploading random JARs separately is usually not the right approach in hosted environments.
Can Tomcat provide my third-party libraries automatically?
Usually no. Tomcat provides container and servlet-related APIs, but third-party libraries such as database drivers or JSON parsers must normally be bundled with the application.
What is the difference between ClassNotFoundException and NoClassDefFoundError?
ClassNotFoundException usually means a class could not be loaded at runtime. NoClassDefFoundError often means the class was available at compile time but is missing now, or one of its dependencies is unavailable.
Can a wrong Java version look like a missing library problem?
Yes. Incompatibility between the compiled bytecode and the selected Java runtime can cause startup or load errors that resemble dependency problems.
How do I avoid this in future deployments?
Always deploy a complete WAR, verify the contents of WEB-INF/lib, use consistent dependency management, and match the application build to the Java version selected in Plesk or My App Server.
Conclusion
Missing libraries are one of the most common reasons a hosted Tomcat application fails after deployment. In a Plesk-managed Java hosting environment, the safest approach is to package all required application libraries in the WAR, confirm the Java version, and deploy only the final build output. This avoids classpath gaps, reduces runtime errors, and makes troubleshooting faster.
If your app uses Tomcat, JSP, servlets, or a private JVM through My App Server, the key rule is simple: what is not in the deployment package is usually not available at runtime. Checking the build output before upload is the best way to prevent application startup failures caused by missing libraries.