When a hosted Java application starts on a shared hosting account, it does not only depend on your source code and web server settings. It also depends on every library, framework, and runtime component that your application expects to find at startup. If one required library is missing, the application may fail during deployment, stop at server startup, or run with partial functionality and later throw runtime errors.
This is one of the most common causes of Java hosting issues in Plesk-based environments, especially when deploying a WAR file or using a private JVM with Apache Tomcat through My App Server. The good news is that most missing-library problems can be diagnosed quickly once you know where to look: the build output, the WEB-INF/lib folder, the classpath, and the Tomcat logs.
Why missing libraries cause hosted Java applications to fail
Java applications are built from classes that are loaded at runtime. If your application tries to use a class from a library that is not present on the server, the JVM cannot resolve it. Depending on when the missing dependency is needed, you may see different errors:
ClassNotFoundExceptionwhen a class cannot be found at runtime.NoClassDefFoundErrorwhen a class was available during compilation but is missing when the application runs.ServletExceptionor framework startup errors when a web framework cannot initialize.Failed to start componentor Tomcat deployment errors when an application context cannot be created.500 Internal Server Errorin the browser when the app starts but fails while processing a request.
In hosted environments, the issue is often not the hosting platform itself. The real cause is usually packaging: the application was compiled successfully on a local machine, but the final deployment package did not include all necessary dependencies.
How this happens in Java hosting and Tomcat deployments
In a standard Java development setup, dependencies are usually managed by Maven, Gradle, or another build tool. During local development, these tools download libraries automatically. On the server, however, only what is packaged into the deployment archive is available unless a shared server library has been deliberately added by the hosting provider.
With Java hosting in a control panel environment such as Plesk and My App Server, the application is typically deployed as a WAR file or run under a configured Tomcat instance. That means:
- your application should include its own runtime dependencies unless the documentation explicitly says otherwise;
- the server does not automatically know about your local build environment;
- a library present in your IDE is not necessarily present in the deployed artifact;
- different Java versions can expose dependency compatibility issues.
This is especially important for JSP hosting, servlet hosting, and small to medium Java applications running on a private JVM. The application must be self-contained enough to run inside the hosted Tomcat service without relying on undeclared local-only resources.
Typical signs that a library is missing
Startup failure after upload
If the WAR file uploads correctly but Tomcat refuses to start the application, check whether a required library is missing from the deployment package. Frameworks such as Spring, Hibernate, Jackson, Log4j, JSTL, or JDBC drivers often cause startup failures when not packaged correctly.
Application deploys, but certain pages fail
Sometimes the home page loads, but a specific action or page throws an exception. This usually means the missing dependency is not needed immediately at startup, but only when a certain feature is used.
Works locally, fails on the hosted server
This is one of the strongest indicators of a packaging problem. Local builds often use the IDE classpath, while hosted deployment uses only the files included in the WAR and the Java runtime selected in My App Server.
Error only appears after a Java or Tomcat version change
If you switch to another Java version or Tomcat version in the hosting panel, a library that used to work may fail because it depends on older APIs or an incompatible servlet container version.
Where to check first in a hosted Java application
1. Check the deployment archive
Open the WAR file or deployment output and verify that it contains the expected structure. For a typical web application, the following locations matter most:
WEB-INF/classesfor compiled application classesWEB-INF/libfor JAR dependenciesWEB-INF/web.xmlif the app still uses a deployment descriptor
If a third-party JAR is missing from WEB-INF/lib, Tomcat cannot load it unless it exists in the server classpath, which is usually not the case in shared hosting.
2. Review the build tool configuration
If you use Maven or Gradle, confirm that the dependency scope is correct. A common mistake is marking a runtime dependency as provided when the server does not actually supply it. Another common mistake is excluding transitive dependencies that your framework still needs.
Examples of risky configuration choices include:
- using
providedfor libraries that are not bundled by the hosting environment; - excluding transitive dependencies without checking the full dependency tree;
- building one artifact locally and uploading a different, outdated artifact later;
- packaging only compiled classes without the library JARs.
3. Check Tomcat logs in Plesk or My App Server
The logs usually show the exact class or package that is missing. In a managed hosting setup, review the application logs and the Tomcat startup logs from the control panel or service interface. The key is to find the first stack trace entry that references the missing class, not just the final error page shown in the browser.
Look for messages containing:
ClassNotFoundExceptionNoClassDefFoundErrorUnsatisfiedLinkErrorServletContextListenerstartup failuresCaused bylines in the stack trace
4. Compare local and server Java versions
A library may compile on Java 17 locally but fail on Java 11 in the hosted environment, or vice versa. Even when the application artifact is complete, version differences can change class loading behavior or API availability. In My App Server, always confirm the selected Java version before testing deployment.
Common packaging mistakes that remove libraries from the final build
Using the wrong dependency scope
One of the most frequent problems is marking a library as available only during compilation. In Maven, a dependency declared as provided is not packaged into the WAR. That is correct only when the container already supplies the library. In a hosted Tomcat environment, many applications need to bundle the library themselves.
Relying on IDE-only classpath entries
Some dependencies are available in the development IDE but are not part of the build script. The project compiles locally because the IDE adds the library manually, but the build output does not include it.
Missing transitive dependencies
A library may depend on other libraries that are not obvious at first glance. If the build tool is configured to exclude transitive artifacts, the application may miss required classes at runtime.
Deploying an incomplete artifact
Sometimes the correct WAR is built, but the wrong file is uploaded to the hosting account. This can happen when old artifacts remain in the project directory or when a CI pipeline publishes an outdated build output.
Conflicting library versions
A different version of the same library may already exist in your application or the server environment. This can cause class loading conflicts, especially if two JARs provide similar packages. The result may not be a clear missing-library error at first, but the effect is similar: the application cannot initialize properly.
How to fix missing libraries in a hosted Java application
Step 1: Identify the exact missing class or package
Start with the first error in the logs. If Tomcat reports ClassNotFoundException: com.example.SomeService, determine which JAR contains that class. If the missing item belongs to a third-party library, it must be present in the deployment package or on the server classpath.
Step 2: Verify that the library is included in the WAR
After building the project, inspect the archive contents. A quick check should confirm whether the required JAR is located in WEB-INF/lib. If it is not there, rebuild with the correct dependency scope and packaging settings.
Step 3: Rebuild from a clean state
Remove old build outputs and generate a fresh artifact. This helps avoid stale JARs, leftover compiled classes, and outdated package definitions. Clean builds are especially useful when you recently changed library versions or build tool settings.
Step 4: Confirm the runtime matches the build assumptions
Make sure the hosted Java version, Tomcat version, and servlet API level match what your application expects. A library that depends on newer language features or APIs may need a different runtime selection in My App Server.
Step 5: Review server-side deployment settings
If you are using Plesk with My App Server, confirm that the application is deployed to the correct service and that the Tomcat instance was restarted after uploading the new build. In some cases, a restart is needed to clear cached class references and load updated dependencies.
Step 6: Re-test with a minimal dependency set
If the application has many libraries, try identifying the smallest set needed to start the app. This can help isolate which dependency is missing or conflicting. Once the core application starts successfully, reintroduce the remaining libraries one group at a time.
Build-output best practices for Java hosting
Packaging matters as much as coding. A reliable Java hosting deployment starts with a correct build output. Use these practices to reduce deployment issues:
- include all required runtime JARs in the WAR unless the container explicitly provides them;
- avoid manual copying of files into build folders unless your process is documented and repeatable;
- keep dependency versions aligned across development, test, and production builds;
- generate one clean, versioned artifact for each release;
- check the final package before upload, not just the source project;
- test the application after each major dependency update;
- keep the build configuration in version control.
For hosted Tomcat deployments, a predictable package structure is more important than a complicated build process. A clean WAR with the correct libraries is usually easier to maintain than a deployment that depends on hidden local settings.
How My App Server helps with library-related deployment issues
My App Server is designed for practical Java hosting in a shared hosting account. Through the Plesk extension, you can manage a private JVM and a Tomcat instance without needing a separate dedicated application server. This is useful when you want a controlled environment for WAR, JSP, and servlet applications.
From a dependency perspective, the main advantage is clarity: you know which Java version and Tomcat instance your application is using, and you can manage service state directly from the panel. That makes it easier to verify whether a problem is caused by the build output or by the runtime configuration.
In many cases, the fastest path to resolution is:
- confirm the selected Java version;
- check the Tomcat logs;
- verify the WAR contents;
- rebuild with the missing JARs included;
- redeploy to the same service.
Examples of libraries that are often missing
Framework libraries
Spring, Struts, Hibernate, JSF, and similar frameworks often require a complete set of JARs. Missing one module can prevent application startup.
JSON and XML processing libraries
Jackson, Gson, JAXB-related components, or XML parsers may be present during local development but missing from the deployed archive.
JDBC drivers
Database connectivity is a frequent source of runtime errors. If the JDBC driver is not included where your application expects it, connection creation fails even though the application may start.
Logging libraries
Logging frameworks can also break startup if an expected binding or adapter is absent. This is common when switching between logging implementations or updating dependencies.
Utility and support libraries
Libraries for file upload, image processing, validation, or templating are often added late in development and forgotten during packaging.
How to prevent missing-library errors before deployment
The best fix is prevention. Before you upload a Java application to hosted Tomcat, run a deployment checklist:
- Build from a clean workspace.
- Open the generated WAR and verify
WEB-INF/lib. - Confirm the selected Java version in the hosting panel.
- Check whether any dependency is marked as
providedincorrectly. - Compare the production artifact with the local test artifact.
- Review logs immediately after deployment.
- Document any server-specific library assumptions.
If your application requires a custom set of libraries, test that exact package structure in the same Tomcat environment you use for hosting. That reduces surprises when the app moves from your workstation to the managed hosting account.
When the issue is not the library itself
Not every class-loading error means a missing JAR. Sometimes the file exists, but the application still fails because of one of these reasons:
- the library version is incompatible with the current Java runtime;
- the dependency was placed in the wrong folder;
- another JAR provides the same class and causes a conflict;
- a required native component is not available on the server;
- the app expects a container-managed library that the shared hosting service does not provide.
In these cases, the solution is still to inspect the package structure and runtime configuration, not only the source code. The logs usually reveal whether the problem is absence, conflict, or incompatibility.
FAQ
Why does my Java app work locally but not on the hosting server?
Because your local environment may include libraries that are not part of the deployed WAR. The server only sees the final build output and the selected Java runtime.
Should I place third-party JARs in WEB-INF/lib?
Yes, for most hosted Java web applications. This is the standard place for application-specific libraries in a WAR file.
Can I rely on Tomcat to provide all dependencies?
No. Hosted Tomcat usually provides the servlet container, not your application libraries. Only rely on server-provided components if your hosting documentation explicitly says they are available.
What is the difference between ClassNotFoundException and NoClassDefFoundError?
ClassNotFoundException usually means the JVM could not find a class at runtime. NoClassDefFoundError often appears when a class was available during compilation or earlier startup phases but is missing or failed to load when needed.
How can I tell which library is missing?
Start with the first stack trace line that mentions a missing class. Then identify which JAR normally contains that class. The error message usually points directly to the dependency or package name.
Do Java version changes affect library loading?
Yes. A library may require a newer Java version, or it may depend on APIs that are no longer available. Always test after changing the runtime selected in your hosting panel.
Can I fix missing libraries without changing code?
Often yes. Many issues are solved by correcting the build configuration, including the right JARs in the WAR, or redeploying the proper artifact.
Conclusion
Missing libraries are one of the most common causes of failure in hosted Java applications. In a Plesk and Tomcat environment, the problem usually comes down to packaging, dependency scope, or runtime mismatch rather than the hosting platform itself. If your application fails after deployment, inspect the WAR file, check WEB-INF/lib, review the Tomcat logs, and confirm the selected Java version in My App Server.
For small and medium Java, JSP, and servlet applications, a well-built deployment package is the key to stable hosting. When the build output contains every required library and the runtime is configured correctly, most class-loading and startup problems can be avoided before they reach production.