Startup errors in a hosted JSP app usually mean that Tomcat, the Java runtime, the application package, or a required file/path is not ready when the service starts. In a shared hosting environment with Plesk and a private JVM, these problems are often easier to diagnose than they first appear, because most failures come from a small set of causes: an incompatible Java version, a broken WAR deployment, missing permissions, bad configuration in context.xml or web.xml, port conflicts, or app-specific initialization errors.
If your JSP site runs through a managed hosting control panel such as Plesk and a Java app service like My App Server, the key is to check startup in layers: service status, Java version, Tomcat logs, application logs, and then the application package itself. This article explains the most common causes of startup errors in a hosted JSP app in the UK and how to fix them methodically.
Why JSP apps fail to start in hosted environments
JSP applications do not start like static websites. A JSP app needs a servlet container such as Apache Tomcat, a compatible Java version, a correctly built web archive, and enough resources to finish initialization. During startup, Tomcat loads the web application, reads deployment descriptors, creates the application context, and executes any initialization code. If any of those steps fails, the app may remain unavailable, restart repeatedly, or show a 500 error.
In hosted JSP and Tomcat setups, startup issues typically fall into one of these groups:
- Java version mismatch between the app and the configured JVM.
- Invalid or incomplete WAR file.
- Missing classes, libraries, or configuration files.
- Incorrect file permissions or ownership.
- Application tries to connect to a database or service during startup and fails.
- Out-of-memory errors or other resource limits.
- Misconfiguration in Tomcat, Plesk, or the My App Server service.
- Port, connector, or context path conflicts.
Most common startup error causes in a hosted JSP app
1. Java version mismatch
This is one of the most common reasons a hosted JSP app starts in one environment but fails in another. Your application may have been compiled for a newer Java release than the runtime currently selected in the hosting panel. The reverse can also happen: the app may rely on older APIs or libraries that no longer behave the same way on a newer Java version.
Typical symptoms include:
UnsupportedClassVersionErrorClassNotFoundExceptionfor Java platform classes that are present only in another release- Startup failure immediately after deployment
What to check:
- Which Java version is assigned to the app server in Plesk.
- The Java version used to compile the application.
- Whether any third-party library requires a specific Java release.
How to fix it: select the correct Java version in the service settings if it is available. If the application was built for a newer version than the hosting service supports in your current setup, rebuild the app for a compatible target or choose a compatible runtime from the available My App Server options.
2. Broken or incomplete WAR deployment
When a WAR file is missing classes, has a wrong directory structure, contains corrupted files, or was uploaded before the build finished, Tomcat may fail during application startup. A WAR package must include the expected folder layout, compiled classes, libraries, and configuration files in the correct places.
Typical symptoms include:
- Tomcat starts, but the application context does not appear
404when opening the app path- Errors such as
ZipException,FileNotFoundException, or unpacking issues in the log
What to check:
- That the WAR is complete and not truncated.
- That the archive was generated by the build tool successfully.
- That the deployment location is correct.
- That the application expands properly after upload.
How to fix it: redeploy a fresh WAR from a clean build. If you deploy from an IDE or CI process, make sure the package is uploaded only after the build finishes and the artifact is not locked or partially written.
3. Missing libraries or classes
Many startup failures happen because the application depends on a library that is present locally but not deployed to the hosting environment. In JSP and servlet apps, this often affects startup because the application context tries to load beans, filters, listeners, or datasource classes immediately.
Typical symptoms include:
ClassNotFoundExceptionNoClassDefFoundError- Failures in servlet initializers or listener startup
What to check:
- Whether all required JAR files are included in
WEB-INF/lib. - Whether you accidentally rely on a library from your local machine or IDE only.
- Whether the library version matches your Java version and Tomcat version.
How to fix it: bundle the missing dependencies into the application package or update the build configuration so they are included in the final WAR. Avoid keeping important runtime dependencies only in a developer environment.
4. Configuration errors in web.xml, context files, or app settings
Incorrect XML syntax, wrong servlet mappings, invalid resource references, or malformed context configuration can prevent a JSP application from starting correctly. Even a small typo in a deployment descriptor can stop the application before the first page is served.
Typical symptoms include:
- Startup fails with XML parsing errors
- Servlets, filters, or listeners do not load
- Application loads partially but errors appear in initialization
What to check:
web.xmlsyntax and schema version.- Any context-specific files used by Tomcat or Plesk.
- Property files, environment-specific settings, and resource names.
How to fix it: validate XML files carefully, compare the live deployment with a known good version, and confirm that resource names match exactly. If the app uses profiles or environment variables, make sure the hosted values are present and correct.
5. Database connection failures during startup
Many JSP apps attempt to connect to a database as soon as the application context loads. If the database URL, username, password, driver, or network access is wrong, the whole app may fail to start even though Tomcat itself is healthy.
Typical symptoms include:
SQLExceptionduring startup- Connection pool initialization failures
- Timeouts while loading the app
- Application starts only after a long delay, then fails
What to check:
- Database credentials and host name.
- Whether the JDBC driver is present and compatible.
- Whether the database allows connections from the hosting environment.
- Whether the application requires SSL or special connection parameters.
How to fix it: confirm the database settings first, then test the connection outside the full application if possible. If startup should not depend on the database being available, adjust the app so that non-critical database initialization does not block the whole deployment.
6. File permission or ownership issues
In hosted environments, the application must be able to read configuration files, write logs if needed, and access any directories used for uploads or temporary files. If permissions are too restrictive, startup can fail when the app tries to open a path or create a working directory.
Typical symptoms include:
Access deniedPermission denied- Failure to create temp files, logs, or cache directories
What to check:
- Whether the app can read its own configuration files.
- Whether writable directories exist and are assigned correctly.
- Whether the app uses absolute paths that do not exist in the hosted account.
How to fix it: keep the app within the paths provided by the hosting account, use relative paths where possible, and ensure the service has access to directories that must be writable. In a managed panel setup, use the file manager or service settings to confirm the paths are correct.
7. Out-of-memory or resource limit problems
Even small and medium JSP applications can fail at startup if they need more memory than the assigned JVM can use. This can happen with large frameworks, a long classpath, heavy XML processing, or startup code that loads a lot of data at once.
Typical symptoms include:
OutOfMemoryError- Application starts very slowly and then stops
- Tomcat restarts or the service becomes unstable
What to check:
- Java heap size settings for the private JVM.
- How much memory the app uses during startup.
- Whether the app loads large files or caches on boot.
How to fix it: reduce startup workload if possible, tune heap settings carefully within the limits of the hosting service, and avoid unnecessary initialization work during boot. If the app depends on large memory allocations, review whether it fits the current hosting model.
8. Port, connector, or service conflicts
With a private Tomcat or custom app server, startup can fail if the service tries to bind to a port that is already in use, or if a connector is misconfigured. This is more likely when custom versions are uploaded or when settings are changed manually.
Typical symptoms include:
Address already in use- Connector startup errors
- Service control panel shows the app as stopped or failed
What to check:
- Tomcat connector configuration.
- Whether a custom port overlaps with another service.
- Any manual edits in server configuration files.
How to fix it: restore valid connector settings or use the service controls in Plesk to return to a known working configuration. If you uploaded a custom app server version, verify that its ports and paths are aligned with the service settings.
How to troubleshoot startup errors step by step
Step 1: Check the service status in the control panel
Start with the app server itself. In a managed Plesk environment, confirm whether My App Server is running, stopped, restarting, or failing immediately after launch. If the service will not stay up, the issue is usually at the service, Java, or Tomcat level rather than in a single JSP page.
Step 2: Review the logs first
Logs usually show the exact failure point. Check:
- Tomcat startup logs
- Application logs
- Java stack traces
- Container error output
Look for the first real exception, not only the last line. A startup failure often produces multiple follow-up messages after the original cause.
Step 3: Confirm Java and Tomcat compatibility
Make sure the selected Java version and Tomcat version support the application. If your app was built for a certain servlet API or Java level, it may fail on a different runtime. In a hosting platform with several ready-to-install Java/Tomcat versions, choose the one that matches the app’s build requirements.
Step 4: Validate the deployment package
Check the WAR structure, dependencies, and configuration files. A clean rebuild is often faster than trying to repair a damaged artifact. If the application was deployed manually, repeat the upload using a fresh package and then compare the extracted contents.
Step 5: Isolate application startup code
If the container starts but the app fails, the problem may be in a listener, filter, framework bootstrap class, or database initialization logic. Try to reduce startup work by temporarily disabling non-essential initialization and test again. This helps identify whether the failure is in the app logic rather than in Tomcat itself.
Step 6: Verify file paths and permissions
Check whether the app reads from directories that exist in the hosted account. Also confirm that the app can write to any required cache, upload, temp, or log locations. Relative paths are usually safer than hard-coded absolute paths.
Step 7: Test with a minimal JSP app
If possible, deploy a minimal JSP or servlet example. If the small app starts correctly, the hosting environment and Tomcat service are probably fine, and the issue is specific to your application package or code. If even the minimal app fails, the problem is more likely in the Java service configuration or the container setup.
Common startup error messages and what they usually mean
UnsupportedClassVersionError— the app was compiled with a newer Java version than the runtime.ClassNotFoundException— a required class or library is missing from the deployment.NoClassDefFoundError— a class was available during build or compile time but not at runtime.SQLExceptionduring boot — database connection or JDBC driver problem.Address already in use— port conflict or connector conflict.OutOfMemoryError— JVM memory limit too low for startup needs.- XML parse errors — malformed deployment descriptor or context configuration.
- Permission denied — file access problem in the hosting account.
Best practices to prevent startup failures
- Match the Java version used in development with the one selected in hosting.
- Build and test the WAR locally before upload.
- Keep all runtime dependencies inside the application package.
- Avoid hard-coded absolute file paths.
- Use clear startup logging in the application.
- Do not make critical external services a hard dependency unless necessary.
- Keep Tomcat and your app server configuration simple unless a custom setting is truly required.
- Test updates in a controlled way rather than replacing several components at once.
When the issue is related to My App Server
In a hosting platform with a Plesk extension for Java hosting, startup failures can sometimes be caused by the service configuration rather than the JSP code itself. My App Server is designed to let you run your own Tomcat or private JVM within the hosting account, which is helpful for JSP, servlet, and WAR-based apps. That flexibility also means you should verify the selected Java runtime, the service state, and any custom Tomcat configuration before changing the application code.
If you installed a ready-made Java/Tomcat version, confirm that it was installed successfully and that the service control actions work as expected. If you uploaded a custom app server version, verify the configuration carefully because custom paths, ports, and JVM settings can affect startup immediately.
FAQ
Why does my JSP app work locally but not on the hosted server?
Most often because the hosted runtime uses a different Java version, different Tomcat version, missing dependencies, or stricter file path and permission rules. Local and hosted environments rarely match exactly.
Can a database issue stop the whole app from starting?
Yes. If your application initializes a database connection during startup and the connection fails, Tomcat may load the app incompletely or refuse to finish initialization.
What should I check first when the app shows a startup error?
Start with the logs, then confirm Java version, deployment package integrity, and application dependencies. These four checks solve a large share of startup problems.
Is the problem always in Tomcat?
No. Tomcat often reports the failure, but the root cause is frequently in the application code, a missing library, a bad XML file, or a database connection problem.
Do I need a special setup for JSP hosting?
You need a servlet container such as Tomcat and a compatible Java runtime. In a managed hosting environment, the control panel usually provides the service controls and version selection needed for JSP deployment.
Conclusion
Startup errors in a hosted JSP app usually come down to a small number of predictable causes: Java incompatibility, broken deployment files, missing dependencies, config mistakes, database connection failures, permission issues, or resource limits. In a managed hosting setup with Plesk and My App Server, the fastest path is to check the service state, read the logs, verify the Java and Tomcat versions, and then inspect the WAR package and app configuration.
When you troubleshoot in that order, most startup failures can be identified quickly and fixed without guesswork. For JSP, servlet, and Tomcat hosting, the most reliable deployments are the ones that keep the runtime version aligned, include all dependencies, and use simple, well-tested startup configuration.