If a Java application fails to start in a hosting environment, the cause is usually one of a few common issues: an incompatible Java version, a Tomcat or JVM startup problem, a missing application file, a port conflict, a configuration error, or resource limits reached during deployment. In a managed hosting setup such as Plesk with a Java extension like My App Server, the good news is that most startup failures can be identified quickly by checking the application logs, service status, runtime version, and deployment structure.
On shared Java hosting, startup failures are often related to the application package itself rather than the platform. A WAR file may contain an invalid context, a servlet error, a broken database connection, or a class compiled for a newer Java release than the selected runtime. In other cases, the service starts correctly but the web application cannot initialize because one of its dependencies is missing or misconfigured. The steps below help you narrow down the problem in a practical way.
Why a Java application may fail to start
A Java application usually passes through several stages before it becomes available in the browser. First, the Java runtime starts. Then the servlet container, such as Apache Tomcat, loads the application. After that, the application initializes its classes, reads configuration files, connects to external services, and binds to the expected context path. A failure at any stage can stop the application from starting.
In a hosting platform with a control panel, the most common reasons include:
- Wrong Java version selected for the application
- Tomcat or private JVM service stopped, hung, or not launching
- Application archive is incomplete or deployed in the wrong format
- Servlet, JSP, or Spring startup error inside the application code
- Port already in use by another service
- Memory or process limits reached
- Incorrect file permissions on the deploy directory
- Missing environment variables, database settings, or configuration files
- Invalid web.xml, context configuration, or annotation scan issue
If you are using a service like My App Server, the startup path is especially important because the application depends on the selected Tomcat or private JVM profile inside your hosting account. That means the platform can provide the Java runtime and service controls, but the application package still needs to be compatible with the chosen version and deployment method.
First checks in Plesk or the hosting control panel
When a Java app does not start, begin with the control panel rather than the browser error page. The control panel usually gives faster clues than the application itself.
Check the application status
Open the Java service or application section in Plesk and confirm whether the app server is running. If the service is stopped, try starting it manually. If it starts and then stops again, this often indicates a startup error in the application or a Java runtime problem.
Check the selected Java version
Many startup failures happen because the app was built for one Java version and deployed with another. For example, a class compiled with Java 17 will not run on Java 11. In the hosting panel, verify that the selected Java runtime matches your application’s requirements.
If your hosting plan provides several ready-made Java/Tomcat versions, test the application with the version recommended by the developer or by the framework documentation. When the application supports multiple versions, choose the closest supported version rather than the newest version by default.
Check the deploy package
Confirm that the application is uploaded as the correct package type, usually WAR for web applications. If you upload a plain folder, a corrupted archive, or an incomplete build output, Tomcat may fail to deploy it. Make sure the archive contains the expected structure, including WEB-INF and the application classes or resources.
Check logs
Logs are the most valuable source of information for startup failures. Review:
- Tomcat logs
- Application logs
- Java service logs
- Web server logs if the app is routed through Apache
Look for SEVERE, Exception, ClassNotFoundException, UnsupportedClassVersionError, BindException, OutOfMemoryError, or database connection errors. These messages usually point directly to the root cause.
Java version mismatch and class compatibility
One of the most common reasons a Java application fails to start in the UK hosting market, as in any managed hosting environment, is Java version incompatibility. The runtime available in the control panel must be compatible with the bytecode and libraries used by the application.
Typical compatibility symptoms
UnsupportedClassVersionErrorClassNotFoundExceptionfor a dependency that should exist- Application starts partially and then exits
- Framework initialization fails immediately after deployment
For example, if your application uses a framework compiled for Java 17, it will not run on a Java 11 runtime. The same applies to libraries that depend on newer language features or newer servlet APIs. If the application worked locally but fails in hosting, compare the local Java version with the one selected in My App Server or in the hosting panel.
What to do
- Identify the Java version required by your application.
- Check the Java runtime selected in the hosting control panel.
- Switch to a compatible version if available.
- Rebuild the application with a lower target version if needed.
- Redeploy the WAR file and test again.
If you manage your own build process, ensure that the compiler target and runtime target match the environment. If you use Maven or Gradle, verify the source and target configuration before deployment.
Tomcat startup problems
If you are hosting a Java web application on Apache Tomcat, startup may fail before your application is even loaded. In that case, the problem is not always inside the application code. It may be related to the Tomcat instance, the configured ports, or the service settings.
Check whether Tomcat is listening on the expected port
A common issue is a port conflict. If another process already uses the port selected for Tomcat, the service cannot bind to it and fails to start. Log entries often include java.net.BindException: Address already in use.
In managed hosting, this may happen if:
- another Java instance is running on the same host account
- a previous Tomcat process did not shut down correctly
- the application uses a custom server port that conflicts with another service
Use the control panel service tools to stop the instance fully, then start it again. If the problem persists, review the service configuration or choose a different port if your setup allows it.
Check Tomcat logs for Catalina errors
Tomcat logs often show messages during container startup. Pay attention to failures in:
catalina.outlocalhost.logmanageror application-specific logs
Messages about missing JAR files, malformed XML, invalid context definitions, or deployment descriptor errors should be treated as configuration problems, not hosting faults.
Restart the service cleanly
If the service appears stuck, perform a clean restart from the hosting control panel. This helps clear zombie processes, leftover lock files, or incomplete startup attempts. If your hosting environment offers service control for My App Server, use that control rather than trying to force changes through the filesystem.
Application package and deployment errors
Many startup failures are caused by the application package itself. The most frequent problem is a bad build artifact or an incomplete deployment.
Check the WAR structure
A valid WAR file should contain the expected Java web application structure. If the archive is broken, Tomcat may accept the upload but fail during deployment.
Look for issues such as:
- missing
WEB-INFfolder - empty
libdirectory when dependencies are required - missing
web.xmlwhen the app depends on it - incorrect context path or deployment name
- nested archive files that were not unpacked correctly
Check for incomplete uploads
Large WAR files may fail to upload completely if the connection drops or if the build process was interrupted. If the deployment directory contains files that were partially written, the app may fail during class loading.
Delete the previous deployment, upload a fresh build, and redeploy. If possible, compare file size and checksum with the source build artifact.
Verify file permissions
Tomcat and the Java service need permission to read the application files and write temporary data. If permissions are too restrictive, deployment can fail during startup. Common symptoms include access denied errors or inability to create temporary directories.
Make sure the application directory, logs directory, and temp folders are accessible to the user account running the service.
Configuration problems inside the application
If the runtime and deployment package are correct, the cause is often a configuration issue inside the application. This is especially common with Java applications that require a database, external API, or environment-specific settings.
Database connection failures
Applications frequently fail to start because they try to connect to a database during initialization. If the credentials, host name, port, or schema are incorrect, the app may stop before it becomes available.
Typical errors include:
- connection refused
- authentication failed
- unknown host
- timeout during initialization
Check whether the database service is reachable from the hosting environment and confirm that the connection string is correct. If the application uses an external database, ensure the firewall and network access settings allow the connection.
Missing environment variables or properties
Some applications expect environment variables, JVM options, or properties files to be set at startup. If these values are missing, the application may fail before it completes initialization.
Review configuration files such as:
application.propertiesapplication.yml- custom
.propertiesfiles - JVM system properties
In managed hosting, set variables through the available control panel options when possible. Avoid hardcoding environment-specific values into the WAR file unless that is the design of the application.
Invalid XML or annotation scanning issues
Tomcat and Spring-based applications may fail when parsing XML configuration or scanning annotations. A small syntax error in web.xml, a malformed Spring bean file, or an incompatible dependency can stop the app from loading.
If the logs mention XML parsing errors or bean creation errors, inspect the last change made to the application. Rolling back the most recent configuration change is often the fastest fix.
Memory, process limits, and startup failures
In shared Java hosting, the application must operate within the plan’s limits. If the JVM or Tomcat requires more memory than available, startup can fail or the process can be killed during initialization.
Symptoms of resource exhaustion
OutOfMemoryError- startup hangs and then stops
- service is killed shortly after launching
- slow startup with repeated retries
Frameworks such as Spring Boot may require more memory during startup than during normal operation. If your application is close to the hosting limit, reduce unnecessary libraries, tune memory usage, or choose a lighter runtime profile if available.
How to troubleshoot resource limits
- Review the service and JVM logs for memory-related errors.
- Check whether the application starts with a smaller dependency set.
- Reduce the initial heap size or other JVM parameters if your hosting plan allows it.
- Restart only one Java instance at a time to avoid overlapping usage.
- Confirm that the application is suitable for shared hosting limits.
For small and medium Java web applications, a private JVM or dedicated Tomcat instance within your hosting account is often enough. For heavier enterprise workloads, startup problems may reflect the application size and architecture rather than the hosting platform itself.
Using My App Server to isolate the problem
If you are using ITA’s My App Server extension, you can separate infrastructure issues from application issues more easily. The service controls let you manage your own Tomcat or private JVM inside the hosting account, which is useful for diagnosing startup failures.
What to verify in My App Server
- Is the correct Java version installed?
- Is the app server service running?
- Was the application deployed to the expected context?
- Are the service logs showing a startup exception?
- Does the application start after a clean service restart?
The main advantage of this model is that you can test the same application against several supported Java or Tomcat versions without changing the rest of your hosting account. That makes it easier to identify version-specific startup failures.
When to use a ready-made version versus a custom app server
If your application is based on a common Java web stack, a ready-made Tomcat version is usually the simplest option. If your application depends on a specific runtime build or a custom server setup, a manually configured app server may be better. However, the goal should still be compatibility and stable startup, not complex enterprise clustering.
Step-by-step troubleshooting checklist
Use the following checklist when a Java application does not start:
- Confirm that the app server or Tomcat service is running.
- Check the selected Java version in the control panel.
- Review the latest logs for the exact error message.
- Verify that the WAR file was uploaded completely.
- Check for invalid XML, class loading errors, or missing dependencies.
- Test the database connection and other external services.
- Restart the service cleanly to clear stale processes.
- Check memory usage and hosting limits.
- Redeploy a fresh build if the current one may be corrupted.
- Try a different supported Java/Tomcat version if compatibility is uncertain.
If the application still does not start after these checks, the issue is usually visible in the logs and can often be resolved by changing one configuration value or rebuilding the application with the right runtime target.
Common error messages and what they usually mean
UnsupportedClassVersionError
The application was compiled for a newer Java version than the runtime currently selected.
ClassNotFoundException or NoClassDefFoundError
A required class or library is missing from the application package or classpath.
java.net.BindException: Address already in use
Tomcat or another Java service is trying to use a port that is already occupied.
OutOfMemoryError
The JVM does not have enough memory to complete startup.
HTTP 404 after deployment
The app may have deployed, but the context path is incorrect or the expected application root is missing.
HTTP 500 on first request
The application started partially but failed during runtime initialization or request processing.
FAQ
Why does my Java application work locally but fail on hosting?
The most common reason is environment mismatch. Local development and hosting can differ in Java version, Tomcat version, memory limits, file paths, and available dependencies. Compare the local runtime with the hosted runtime and check the deployment logs.
How do I know if the problem is Tomcat or my application?
If Tomcat itself fails to start, the issue is usually service-level, such as a port conflict or invalid server configuration. If Tomcat starts but the application fails to deploy, the issue is likely inside the WAR file, dependencies, or application configuration.
Can I change the Java version to fix startup errors?
Yes, if the hosting platform provides multiple Java versions. This is often the fastest fix for compatibility errors. Make sure the chosen version matches both the application build and the libraries it uses.
What logs should I check first?
Start with the Tomcat or app server logs, then review the application logs. If Apache is involved as a front end, also check the web server error log. The first exception in the startup sequence is usually the most useful one.
Why does the app stop immediately after I start it?
This usually means the JVM started, but the application crashed during initialization. Common causes include database connection failures, missing configuration, class loading errors, or memory exhaustion.
Does My App Server support custom Java and Tomcat setups?
Yes, the platform is designed to let you install and manage a private JVM or Apache Tomcat instance inside your hosting account. It is suitable for practical Java hosting, JSP hosting, servlet hosting, and small to medium application deployments.
Conclusion
A Java application that fails to start in a hosted environment is usually affected by a small set of predictable issues: Java version mismatch, Tomcat startup errors, broken deployment packages, missing configuration, database connectivity problems, or hosting limits. In a Plesk-based setup with My App Server, the fastest path to resolution is to verify the service status, compare the selected runtime with the application requirements, and inspect the logs for the first startup exception.
Once you isolate whether the problem is in the runtime, the server, or the application package, the fix is usually straightforward. Most startup failures can be resolved by selecting the correct Java version, redeploying a clean WAR file, adjusting configuration, or restarting the app server service cleanly.