When a JSP application behaves unexpectedly, the first things to check are usually not the application pages themselves, but the hosting settings around the domain, the document root, the Java service, and the way Plesk routes requests to your app server. In a typical Plesk-based hosting setup, small changes in domain configuration can affect whether your JSP files are served correctly, whether Tomcat starts with the right version of Java, and whether the application can read the paths it expects.
For UK-based hosting customers, the practical goal is usually simple: keep the domain configuration clean, make sure the JSP application is mapped to the correct document root, and confirm that the Java runtime and Tomcat service match the app’s needs. If you are using My App Server in Plesk, you can manage a private JVM and Apache Tomcat instance inside your hosting account, which gives you more control without the complexity of a full enterprise Java stack.
Which hosting settings matter most for a JSP app?
The most important settings are the ones that control how the domain is served, where files are stored, and which Java environment runs the application. If any of these are misaligned, a JSP site may show 404 errors, 500 errors, deployment failures, or a blank page after upload.
1. Domain and document root
The domain’s document root is where your web files are expected to live. For JSP hosting, this setting must match the layout used by your Tomcat deployment. If the domain points to the wrong folder, Apache or the application front-end may never reach the JSP application.
Check that:
- the domain is assigned to the correct hosting subscription;
- the document root points to the intended application directory;
- the deployed WAR or webapp files are placed in the path expected by your setup;
- you are not mixing static website files and Java app files in a way that breaks the app structure.
2. Hosting type and web server mode
In Plesk, the hosting mode can influence how requests are handled. Some domains are used as standard websites, while others are configured to pass traffic to Tomcat or to a reverse proxy layer in front of the Java app. For JSP hosting, the hosting mode must be consistent with the app server setup.
If the site should be handled by Tomcat, make sure the domain is configured for the Java application flow you intended. If Apache is fronting the app, check that the proxying or internal mapping is still active and that no conflicting redirect or forwarding rule is overriding it.
3. Java version
JSP and servlet applications can be sensitive to the Java version. A project compiled for one runtime may fail on another if language level, libraries, or server-side dependencies do not match.
With My App Server, you can choose from ready-made Java/Tomcat versions or upload and configure a custom app server where needed. The practical rule is simple: use the Java version that matches your application requirements and keep it consistent across development and hosting.
4. Tomcat service status
If Tomcat is stopped, restarting, or misconfigured, the JSP application will not load properly. In a managed hosting environment, service control is one of the most important checks.
Verify whether:
- the Tomcat instance is running;
- the service started cleanly after the last deployment;
- the app server is attached to the correct domain;
- the service is using the expected configuration files and ports.
5. Port and proxy routing
JSP apps usually do not receive traffic directly on an exposed application port. Instead, Apache, a proxy layer, or Plesk routing rules often forward requests to Tomcat internally. If the port mapping is wrong, the domain may resolve but the application can still fail.
Common symptoms of routing issues include:
- browser timeouts;
- 502 or 503 errors;
- the website showing the Apache default page;
- Tomcat responding locally but not through the domain.
6. Application paths and context root
A JSP app must be deployed under the correct context path. If the context root changes, bookmarks, links, and internal redirects may break. This matters especially when you move an app from one Plesk subscription to another, or when you rename the domain.
Confirm the context root used by your app server and make sure it matches the URL structure you expect.
7. File permissions and ownership
Even when the domain settings are correct, a JSP app can fail if Tomcat cannot read files or write temporary data. Permissions and ownership are especially important for uploaded WAR files, logs, temp directories, and session storage.
Check that the application files are accessible to the service account used by the Java runtime and that the web application has write access only where it truly needs it.
How to check Plesk hosting settings for a JSP application
If you manage your Java hosting through Plesk, use a structured check so you do not miss the most common causes of failure. The following steps are suitable for typical JSP, servlet, and Tomcat-hosted applications.
Step 1: Open the domain settings
Go to the domain in Plesk and review the hosting configuration. Confirm the selected hosting type and the document root. For JSP applications, this should align with the deployment strategy used by your Tomcat instance or My App Server extension.
Step 2: Confirm the assigned app server
If you use My App Server, check that the correct private JVM or Tomcat instance is assigned to the domain. Make sure the intended version is active and not just installed. A version can be present on the account but not attached to the live app.
Step 3: Review the document root and web directory
Verify the path shown in Plesk. Make sure the deployment files are inside the expected folder and that there are no conflicting files from an old website version. If a previous static site still exists in the same location, it may mask the Java application.
Step 4: Check service control
Use the service control area to confirm that Tomcat is running. If the service was restarted recently, review whether it started successfully or whether it failed because of a configuration issue, missing file, or unsupported Java option.
Step 5: Test the application URL directly
Open the domain in a browser and test the main URL and the context path. If the app is deployed under a subpath, make sure you are not testing only the root domain. A healthy JSP app may work at one path while another path returns a 404.
Step 6: Review logs
When something is broken, logs are usually the fastest route to the cause. Check:
- Tomcat logs for startup errors and application exceptions;
- Apache logs for proxy and request routing issues;
- domain error logs for 4xx and 5xx responses;
- deployment logs if the WAR upload or application restart failed.
Step 7: Confirm Java compatibility
If the application worked before and now fails after a change, compare the Java version in use with the version required by the app. A JSP app can break after deployment if it depends on a class library or syntax not supported by the current runtime.
Common hosting settings that can break JSP apps
Some settings cause problems more often than others. These are worth checking first when troubleshooting JSP hosting in Plesk.
- Wrong document root: the domain points to a folder that does not contain the app.
- Wrong context path: the application is deployed under a different URL than expected.
- Stopped Tomcat service: the Java service is not running or failed to start.
- Unsupported Java version: the runtime does not match the app’s requirements.
- Conflicting Apache rules: redirects, proxy settings, or rewrite rules override the app.
- Incorrect file permissions: the app cannot read, write, or create needed files.
- Old deployment files: leftover files from a previous version interfere with the current app.
- Port mismatch: Tomcat listens on one internal port while Plesk expects another mapping.
Best practices for My App Server in Plesk
My App Server is designed for practical Java hosting inside a shared hosting account, so the best approach is to keep the setup simple and consistent. That helps with stability and makes troubleshooting easier.
Use one app server per application purpose
If you have more than one Java app, keep their configuration separated. A private JVM for one domain should not share assumptions with another domain unless you fully understand the impact.
Match the Java version to the app
Choose the Java version your JSP or servlet project was built for. If the app was tested on a specific major version, use that version first before experimenting with a newer one.
Keep deployment clean
When updating a WAR or JSP app, remove outdated files that can conflict with the new version. Old class files, old JSP fragments, and stale configuration files can produce confusing behaviour even when the deployment appears successful.
Use logs as part of the routine
Do not wait for a full outage before reviewing logs. A quick look after deployment can catch warnings about class loading, memory limits, configuration syntax, or missing paths before users notice a problem.
Respect service limits
Shared Java hosting is meant for small and medium applications, not heavy cluster-based systems. Keep memory use, session size, and background tasks within the limits of the hosting plan. If the app is too resource-hungry, it may need a different architecture.
What to verify when moving a JSP app to a new domain
Domain changes are a common source of issues because many settings are tied to the original hostname. When moving a JSP app, review the following carefully:
- update the domain binding in Plesk;
- confirm the new document root;
- check the app server mapping for the new domain;
- review absolute links and hard-coded URLs inside the app;
- verify SSL and HTTPS redirects if they are used;
- restart the app server if the domain-to-service mapping changed;
- test login, file upload, and redirect flows after the move.
If the application uses session tracking or callback URLs, also check whether those settings still point to the correct hostname. A JSP app may appear to load normally while background requests fail silently because one URL still references the old domain.
Troubleshooting checklist for JSP hosting issues
Use this checklist when a JSP site fails to load or behaves unexpectedly in Plesk:
- Confirm the domain is attached to the correct hosting subscription.
- Check whether the document root is correct.
- Verify that Tomcat is running.
- Make sure the expected Java version is active.
- Review recent changes to Apache, proxy, or rewrite rules.
- Inspect Tomcat and domain logs for startup or runtime errors.
- Confirm that the WAR or webapp folder was deployed correctly.
- Check permissions on application directories and temporary paths.
- Test the site in a browser and compare the root URL with the context path.
- Restart the app server after changing core hosting settings.
When the issue is not the application itself
It is common to assume that a JSP bug is in the code, but in hosting environments the root cause is often one layer below the application. For example, a class may fail to load because the Java version changed, or a JSP page may return an error because Tomcat cannot write to its temp directory. Likewise, a domain can appear configured correctly while Apache still forwards requests to an outdated destination.
Before debugging application code, always validate the hosting layer. That includes the domain configuration, app server service state, and any Plesk settings that affect request handling.
FAQ
Which Plesk settings matter most for JSP hosting?
The most important settings are the domain document root, the assigned app server, the Java version, the Tomcat service status, and the routing or proxy configuration. These settings determine whether the JSP application can start and receive traffic correctly.
Why does my JSP site show a 404 in Plesk?
A 404 often means the domain is pointed to the wrong folder, the context path is incorrect, or the app was deployed in a different location from the one the domain is serving. Check the document root and the Tomcat mapping first.
Why does Tomcat start but the site still does not load?
This usually indicates a routing, context path, or deployment problem. Tomcat may be running, but the domain may not be linked to the correct application URL or the Apache proxy may not forward requests properly.
Can I use a custom Java or Tomcat version?
Yes, in many cases you can use a ready-made version or upload and configure a custom app server, depending on the hosting setup. This is useful when an application needs a specific runtime not covered by the standard installation.
What should I check after uploading a WAR file?
Check that the upload completed successfully, the application deployed without errors, the context path is correct, and the service restarted if needed. Then review logs for class loading issues, missing files, or configuration conflicts.
Do I need a separate JVM for each JSP app?
Not always, but a private JVM can make management easier and reduce cross-application interference. For small to medium applications, separating services can simplify updates and troubleshooting.
What if the app worked before and stopped after a settings change?
Start by reviewing the last change to the domain, Java version, document root, or proxy settings. A hosting change often causes JSP failures even when the application code has not changed.
Conclusion
For a JSP application in a Plesk-based hosting environment, the most important settings are the ones that connect the domain to the app server correctly: document root, hosting mode, Java version, Tomcat service status, and request routing. If you are using My App Server, you also gain the practical advantage of managing a private JVM and Tomcat instance directly from your hosting control panel, which makes JSP hosting, servlet hosting, and WAR deployment more straightforward.
When a problem appears, focus on the hosting layer first. Check the domain configuration, confirm the app server is running, review logs, and make sure the Java version matches the application. In most cases, that approach finds the issue faster than looking at code alone.