If a Java deployment fails on shared hosting, the cause is usually one of a few common issues: the wrong Java version, an invalid WAR package, missing environment settings, a startup error in catalina.out, or a service that was not installed or started correctly in Plesk. In a managed Java hosting setup such as My App Server, the fastest way to fix the problem is to check the Tomcat service status, review the logs, verify the deployment package, and confirm that the application matches the selected Java runtime.
This guide explains how to troubleshoot a failed Java deployment on shared hosting, including Tomcat deployment errors, JSP/Servlet startup problems, and common control panel issues. The steps below are written for a hosting environment where you manage your own Java app server from Plesk, with a private JVM or Apache Tomcat instance per account.
Common reasons a Java deployment fails
When a Java application does not start after upload or install, the failure usually happens during one of these stages:
- the application archive is invalid or incomplete
- the selected Java version is not compatible with the app
- Tomcat cannot read the deployment path or files
- the application depends on missing libraries or configuration files
- the app crashes during startup because of an exception
- the service is stopped, misconfigured, or out of resources
In a shared hosting environment, these problems are often visible in the application logs, the Tomcat logs, or the service control screen in Plesk. If your hosting platform provides a Java hosting extension such as My App Server, use it first, because it centralizes service management and makes it easier to isolate the problem.
Check whether the Tomcat or Java service is running
Before changing the application itself, confirm that the Java service is active. A deployment can fail simply because the app server did not start after installation or was stopped manually.
What to verify in the control panel
- the My App Server service is installed for the subscription or domain
- the correct Tomcat instance is assigned to the application
- the service status shows as running
- there are no failed restart attempts
- the selected Java version is available and supported
If the service is stopped, start it from the control panel and wait a minute before testing the site again. If it starts and then stops immediately, the application likely has a startup error, a port conflict, or a configuration issue.
What to do if the service will not start
If the service control shows a startup failure, open the logs before making changes. On managed hosting, the logs usually reveal whether the issue is in the application, the runtime, or the server configuration. Common symptoms include:
ClassNotFoundExceptionNoClassDefFoundErrorUnsupportedClassVersionErrorPort already in usePermission deniedOutOfMemoryError
Review the Tomcat and application logs
Logs are the most important source of information for failed Java deployments. In Tomcat-based hosting, the main files to check are usually:
catalina.out- Tomcat startup logs
- application-specific logs
- web application error logs, if configured
Look for the first error in the sequence, not only the final shutdown message. The first exception usually points to the real problem.
How to read the log output
If the application fails during deployment, the log often shows one of the following patterns:
- Deployment descriptor error – the
web.xmlfile or annotation-based configuration is invalid - Missing dependency – a required JAR file is not present in
WEB-INF/lib - Database connection failure – the app cannot connect to MySQL, MariaDB, or another backend
- JVM mismatch – the code was compiled for a newer Java version than the selected runtime
- Resource path problem – files are referenced with a path that does not exist on shared hosting
If the logs are not obvious, search for the earliest SEVERE, ERROR, or stack trace line. That line often identifies the class or configuration file that caused the deployment to fail.
Verify the Java version before redeploying
One of the most common causes of a failed Java deployment is using the wrong Java runtime. A newer application may require Java 11, Java 17, or another version, while older apps may depend on legacy syntax or libraries.
Typical version mismatch errors
UnsupportedClassVersionErrorclass file has wrong versionmajor.minor version mismatch
If you see one of these messages, the application was compiled with a newer Java version than the server supports. In a hosting platform with selectable runtimes, switch the app to the correct Java version and redeploy the WAR file.
How to fix Java version problems
- Check the application documentation or build file for the required Java version.
- Open the Java hosting settings in Plesk or the My App Server extension.
- Select the matching runtime if it is available.
- Restart the service after changing the version.
- Redeploy the application and test again.
If the application needs a version that is not currently selected, use the supported Java version closest to the app requirements, or update the app source code and rebuild it for the version your hosting plan provides.
Check the deployment package structure
On shared hosting, a failed Java deployment is often caused by an incorrect WAR file or an incomplete upload. Tomcat expects a specific application structure, and even a small packaging issue can prevent startup.
What a valid Java web application should include
WEB-INF/directoryWEB-INF/web.xmlif the application uses a deployment descriptor- compiled classes in
WEB-INF/classes - library JARs in
WEB-INF/lib - static resources in the correct path
If you are deploying a WAR file, make sure it is not corrupted. Rebuild the package from a clean source directory rather than reusing a file that may have failed during export or upload.
Common packaging mistakes
- nested folder inside the WAR, such as
app/app/WEB-INF - missing
WEB-INFdirectory - incorrect capitalization in filenames or paths
- extra development files included in the archive
- uploading a ZIP file instead of a WAR file
If your hosting platform supports manual app server setup, verify that the deployment directory points to the right application root and not to a parent folder or temporary upload location.
Confirm file permissions and ownership
Even when the package is correct, Tomcat may fail to deploy the application if it cannot read the files or write temporary data. This is common on shared hosting when uploads are incomplete or permissions are too restrictive.
Permissions to review
- read access for application files
- execute access for directories where needed
- write access for logs, cache, and upload folders
- correct ownership after FTP, File Manager, or external upload tools
For Java applications, make sure the folders used for session storage, uploads, exports, and temporary files are writable by the app server process. If the application starts but crashes during initialization, permission issues are a likely cause.
Look for missing libraries and configuration files
Some Java deployments fail because the application depends on external libraries or environment-specific configuration. This is especially common with older JSP or Servlet applications that expect files from a local development environment.
Typical missing items
- JAR files not included in
WEB-INF/lib - environment variables not defined in the hosting panel
- database config files missing from the deployed package
- secret keys or properties files that were not uploaded
- hardcoded paths from Windows or local development machines
If the application expects values from .properties files, check that the file names and paths are correct and that the file is included in the deployed environment. On shared hosting, relative paths are usually safer than absolute paths.
Check database connectivity
Many Java applications fail at startup because they cannot connect to the database. The deployment may upload correctly, but the app still stops during initialization if the database URL, username, password, or driver is wrong.
What to verify
- database host name is correct
- database port is open and reachable
- database username and password are valid
- the JDBC driver is included
- the connection string uses the right format
In logs, database issues often appear as connection timeout errors, authentication failures, or driver class errors. If your app server is running but the site still shows an error page, database failure is a strong possibility.
Restart the app server after making changes
After fixing the package, the Java version, or the configuration, restart the service before testing again. Tomcat may keep old class files, cached settings, or stale sessions if it is not restarted cleanly.
Why restart matters
- it clears cached deployment state
- it reloads the selected Java runtime
- it applies updated environment settings
- it releases locked files and ports
If the hosting control panel offers separate controls for stop, start, and restart, use restart after a configuration change. If the app still fails, remove the old deployment and deploy a fresh copy of the WAR file.
Test with a minimal version of the application
If a large application keeps failing and the logs are unclear, test with a smaller deployment. A minimal JSP, Servlet, or sample WAR can confirm whether the issue is with the hosting environment or the application itself.
Why this helps
- it separates hosting issues from code issues
- it confirms that Tomcat is working
- it verifies that the selected Java version is usable
- it reduces the number of variables during troubleshooting
If a simple sample app starts correctly, the hosting setup is likely fine and the failure is inside your original application package, configuration, or dependencies.
Check resource limits on shared hosting
Shared hosting has defined limits, and Java apps can fail if they exceed available memory, CPU time, or process limits. Even a small application can stop during startup if it tries to load too many classes, large data sets, or unnecessary background tasks.
Signs of resource-related startup failure
- slow startup followed by service termination
OutOfMemoryError- timeouts during initialization
- repeated restarts or crash loops
Review the hosting limits in the control panel. If your app has outgrown a shared setup, simplify the startup process, reduce memory usage, or split the workload. For small and medium Java, Tomcat, JSP, and Servlet applications, a private JVM within shared hosting is often enough, but it still needs to stay within the platform limits.
Practical step-by-step fix for a failed deployment
If you want a fast troubleshooting path, use this sequence:
- Open the My App Server or Tomcat control screen in Plesk.
- Confirm that the service is running and assigned to the correct domain.
- Check the selected Java version.
- Review the latest application and server logs.
- Look for the first startup exception.
- Verify the WAR file structure and rebuild it if needed.
- Check file permissions, ownership, and writable directories.
- Confirm database settings and required libraries.
- Restart the service and redeploy a clean copy.
- Test again with a minimal application if the problem remains.
This method covers the most common deployment failures in Java hosting and usually identifies the root cause quickly.
How this works in My App Server hosting
In a hosting environment with My App Server, you can usually manage a private Tomcat instance and choose from available Java versions directly in the control panel. This is useful for WAR-based apps, JSP hosting, servlet hosting, and smaller Java applications that need their own JVM without the complexity of a full enterprise stack.
The main advantage is control: you can start, stop, and restart the service, select a runtime, and deploy a custom Java application in one place. That makes failed deployments easier to troubleshoot than in a setup where the app server is fully hidden from the user.
At the same time, the platform is designed for practical shared hosting use cases. It is not meant to replace a heavy enterprise application server environment, complex clustering, or advanced high-availability architecture. For typical Java web apps, though, it gives you the right balance between convenience and control.
When to rebuild and redeploy from scratch
Sometimes the fastest fix is a clean redeploy. Do this when:
- the WAR file was uploaded multiple times and the state is unclear
- the deployment directory contains old files
- the app worked before, but now fails after partial updates
- the logs suggest a broken or incomplete package
Before redeploying, remove the failed application version, clear any temporary deployment artifacts if the control panel allows it, and upload a fresh build from your source project. A clean redeploy prevents cached files from masking the real issue.
FAQ
Why does my Java app upload successfully but still fail to start?
Upload success only means the file reached the server. The app can still fail because of a Java version mismatch, a bad WAR structure, missing dependencies, database problems, or a startup exception in the logs.
What log file should I check first?
Start with catalina.out and the latest Tomcat startup logs. If your application has its own log file, check that too. Look for the first error before the service stops.
What does UnsupportedClassVersionError mean?
It means the application was compiled with a newer Java version than the runtime currently selected on the server. Switch to a compatible Java version or rebuild the app for the installed version.
Can a permissions problem stop a Java deployment?
Yes. If Tomcat cannot read the application files or write to required folders, the deployment may fail or the app may crash during startup.
Should I use a ZIP file or a WAR file?
For Tomcat deployment, use a WAR file unless your hosting instructions say otherwise. A ZIP archive may upload correctly but still fail because Tomcat expects a proper web application structure.
What if the app only fails on one domain but works elsewhere?
That usually points to a domain-specific configuration issue, such as a different Java version, different context path, a missing database setting, or different file permissions in that account.
Conclusion
A failed Java deployment on shared hosting is usually fixable once you check the service status, read the logs, and confirm that the application matches the selected Java runtime. In a Plesk-based Java hosting setup with My App Server, the most effective troubleshooting steps are to verify the Tomcat service, review startup errors, rebuild the WAR file if needed, and check permissions, dependencies, and database connectivity.
If the app still will not start after a clean redeploy, compare the logs from a minimal test application with your production package. That will help you determine whether the issue is in the hosting configuration or in the application itself. For most startup and deployment failures, a structured review of logs and runtime settings is enough to restore the app without changing the hosting environment.