When a hosted Tomcat application starts with ClassNotFoundException, NoClassDefFoundError, or a similar startup failure, the cause is often not Tomcat itself. In many cases, the application was deployed without all required libraries, or the build output was packaged in a way that leaves out JAR files the app needs at runtime.
In a managed Java hosting environment such as My App Server in Plesk, this usually means the application was uploaded successfully, but the final WAR or exploded deployment is incomplete. Tomcat can only load classes that are present in the application package or in the server’s library paths. If a dependency is missing, the app may fail during startup, show errors on the first request, or behave unpredictably after deployment.
Why missing libraries cause Tomcat deployment failures
Tomcat runs your Java web application with a classloader model. Your app can use classes from:
- its own application package, usually under
WEB-INF/classes - JAR files in
WEB-INF/lib - Tomcat’s shared or global library locations, if configured
- the selected JVM and Java runtime
If a required library is not available in any of these locations, the application cannot load the class it references. That can happen for many reasons:
- the build tool did not include the dependency in the final artifact
- the library was marked as
providedbut Tomcat does not supply it - a manual deploy missed one or more JAR files
- the application depends on a version of a library that is different from the one on the server
- the project builds correctly in the IDE but the packaged WAR is incomplete
For hosted Tomcat applications, the most common problem is not the server configuration itself, but the contents of the deployable package.
Typical error messages you may see
Missing libraries usually show up in one of these forms:
java.lang.ClassNotFoundExceptionjava.lang.NoClassDefFoundErrorjava.lang.UnsupportedClassVersionErrorjava.lang.UnsatisfiedLinkErrorin some native-library cases- Tomcat startup errors in
catalina.outor application logs
These messages point to different causes, but the first two are the most common when a JAR file is missing from the deployment package.
Difference between build output and runtime dependencies
To troubleshoot correctly, it helps to separate build output from runtime dependencies.
Build output
This is the final package that you upload to Tomcat. It may be a WAR file or an exploded web application directory. The build output should contain everything the application needs at runtime.
Runtime dependencies
These are the libraries your application uses when running. Some dependencies are needed only during compilation, while others are required both at compile time and runtime.
A common mistake is assuming that a project builds successfully, so it must be deployable. In reality, the IDE or build system may resolve dependencies from a local cache or development environment that is not present on the hosting account.
How this happens in Maven, Gradle, or manual builds
Different build systems fail in different ways, but the result is the same: the deployable package is missing one or more libraries.
Maven projects
In Maven, dependencies marked as provided are not included in the WAR. That is correct for libraries supplied by the server, but incorrect for application-specific JARs that Tomcat does not provide.
Other issues include:
- dependencies declared in the wrong scope
- an incomplete
maven-war-pluginconfiguration - exclusions that remove needed transitive dependencies
- older plugins producing unexpected WAR contents
Gradle projects
In Gradle, the most common mistake is using the wrong configuration, such as compileOnly instead of implementation or runtimeOnly. If the library is not part of the runtime classpath, it will not be included where Tomcat can load it.
Manual packaging
If you deploy by hand, you must copy all required JAR files into WEB-INF/lib. It is easy to forget a transitive dependency, especially if your application depends on a framework such as Spring, Hibernate, Jackson, or a third-party JDBC driver.
How to check whether a library is missing
When an application fails on a hosted Tomcat service, use a structured checklist.
1. Read the first relevant stack trace line
Do not focus only on the final error line. The most useful clue is usually the first class that could not be loaded. For example:
- a servlet class
- a framework class
- a JSON parser class
- a JDBC driver class
That name often reveals which JAR is missing.
2. Inspect the WAR contents
Unpack the WAR file and check whether the expected files are present:
WEB-INF/classescontains your compiled application classesWEB-INF/libcontains dependency JARs- all required internal modules are present
If the JAR is not there, the issue is in the build or packaging step, not in Tomcat.
3. Compare the working development environment with the server
Sometimes the application works locally because the IDE adds libraries automatically. On the hosted server, only the deployed package matters. Check whether your local runtime includes dependencies that are missing from the production WAR.
4. Confirm the selected Java version
A hosted Tomcat app may fail if it was built for a newer Java version than the private JVM selected in My App Server. This is not a missing library in the strict sense, but the symptom can look similar. If you see UnsupportedClassVersionError, verify the Java version first.
5. Review Tomcat logs in Plesk
In a managed hosting setup, logs are usually the fastest way to identify the missing class. Check the application logs and Tomcat logs from the control panel or the service log files. Look for the first deployment error, not only the final failure message.
Packaging rules for hosted Tomcat applications
To avoid deployment problems, the application package should be self-contained unless a library is explicitly shared by the server.
Include all runtime JARs in the WAR
For a typical Tomcat hosting setup, the safest approach is to place all application runtime libraries in WEB-INF/lib. This is the standard and most predictable packaging model.
Keep server-side libraries separate
Do not rely on libraries being installed globally on the host unless the hosting provider documentation says they are available for your service. In shared Java hosting, the application should usually bring its own dependencies.
Avoid mixing versions
If your application expects version 2.x of a library but the server provides version 1.x, you may see method-not-found errors or class loading conflicts. When possible, package the exact version your application was compiled and tested with.
Use the correct artifact type
For Tomcat, deploy a WAR or exploded web application directory. A plain JAR is not usually enough for servlet-based apps unless the project is specifically designed to run that way.
Practical example: a WAR builds, but Tomcat fails
Imagine a web application that uses a PDF generation library and a JSON library. The project builds successfully on a developer laptop. The WAR is uploaded to the hosting account through Plesk, but Tomcat fails during startup.
After checking the logs, the first error points to a class from the JSON library. The WAR is unpacked, and the JAR is missing from WEB-INF/lib. The cause is not Tomcat, Apache, or the JVM. The build produced a WAR that excluded the dependency.
The fix is to adjust the build configuration so the library is included in the runtime artifact, then redeploy the corrected WAR through My App Server.
How to fix missing library issues step by step
Use this workflow when a hosted Tomcat application does not start after deployment:
- Open the Tomcat or application logs in Plesk.
- Identify the first
ClassNotFoundExceptionorNoClassDefFoundError. - Map the missing class to its JAR dependency.
- Check the WAR or deployment directory for that JAR.
- Review your build configuration for scope or packaging mistakes.
- Rebuild the application artifact.
- Redeploy the corrected WAR through the control panel.
- Restart the Tomcat service if required by your hosting setup.
If the application still fails, repeat the process with the next missing class in the stack trace. One missing dependency can expose another after the first one is fixed.
When the library is present but the app still fails
Sometimes the JAR exists in the deployment package, yet the application still cannot load it. In that case, the issue may be one of the following:
- the class is in the wrong folder inside the WAR
- there are duplicate versions of the same library
- the application uses incompatible APIs
- the library requires a newer Java version
- the class is loaded by a different web application classloader
On a hosted Tomcat service, duplicate or conflicting JARs are common when an app is built from multiple modules or when older dependencies were left behind during redeploy.
Best practices for Java hosting on My App Server
For reliable deployment in a Plesk-based Tomcat hosting environment, follow these practices:
- build and test the WAR before uploading it
- package all runtime dependencies with the app
- avoid depending on local IDE libraries
- match the Java version used for build and runtime
- keep the deployment clean by removing old exploded folders when necessary
- check logs after every redeploy
- use the control panel to manage the Tomcat service consistently
My App Server is well suited for small and medium Java, JSP, and servlet applications that need their own Tomcat instance or private JVM within a shared hosting account. For this use case, correct packaging is one of the most important parts of a successful deployment.
Common mistakes that lead to missing libraries
- building against libraries that are not included in the WAR
- assuming Tomcat supplies application frameworks
- copying only compiled classes and forgetting dependency JARs
- leaving old files in the deployment directory after updating the app
- using an IDE run configuration instead of the real packaged artifact
- mixing application server libraries with app-specific libraries
FAQ
Does Tomcat automatically download missing libraries?
No. Tomcat does not fetch application dependencies automatically. The required JAR files must already be included in the application package or available in a configured server library path.
Should I place all JAR files in Tomcat’s global library folder?
Usually no. For hosted applications, it is better to package dependencies inside the WAR unless the hosting documentation says a library is shared and supported at the server level.
Why does the app work in my IDE but not on the hosting account?
Your IDE may add libraries from the local environment, while the hosting server only sees the deployed WAR. If a dependency is missing from the package, the application can fail after upload.
What is the difference between ClassNotFoundException and NoClassDefFoundError?
ClassNotFoundException usually means a class could not be found at load time. NoClassDefFoundError often means the class was available at compile time but is missing or failed to load at runtime.
Can a Java version mismatch look like a missing library problem?
Yes. Some startup failures look similar. If the log mentions class file version or unsupported version, confirm that the selected JVM in My App Server matches the version used to compile the application.
What should I redeploy after fixing the build?
Upload the corrected WAR or update the exploded deployment, then restart or reload the Tomcat service if your hosting setup requires it. Always verify the logs after deployment.
Conclusion
Missing libraries are one of the most common reasons a hosted Tomcat application fails after deployment. In most cases, the problem is caused by incomplete build output, wrong dependency scope, or a packaging mistake rather than by Tomcat itself. The most reliable fix is to inspect the WAR, confirm that every runtime dependency is included, and redeploy a clean build through the hosting control panel.
In a Java hosting environment with My App Server, the combination of a private Tomcat instance, a selected JVM, and Plesk-based service control makes deployment manageable, but the application must still be packaged correctly. If your app starts locally but fails on the hosting account, the first place to look is almost always the build output and the libraries inside it.