When a JSP application loads from the wrong path, the cause is usually a mismatch between the application’s context root, the deployed directory name, and the public URL configured in Apache, Plesk, or Tomcat. In a hosting environment, this often happens after a release, a rename, or a manual upload of a WAR file or exploded application folder. The result can be that your site opens under an unexpected URL, static resources return 404 errors, or the application works only when you add an extra folder name to the path.
In a managed Java hosting setup with Tomcat or a private JVM, the path shown in the browser is typically controlled by the web application context rather than by the file location alone. That means a file placed in the correct directory can still load from the wrong public path if the context root, deployment name, proxy rules, or Apache aliases are not aligned.
Why a JSP application may load from the wrong path
JSP applications are usually deployed as a web application with a context path. Tomcat then maps that context path to the application. If the mapping does not match what you expected, the application will appear under a different public URL.
- Wrong context root: The application is deployed as /app instead of /, or vice versa.
- Deployment folder name mismatch: The WAR file name or exploded directory name becomes the URL path.
- Multiple deployments: An old version remains active alongside the new release.
- Apache proxy or rewrite rules: Requests are forwarded to Tomcat with an unexpected path.
- Relative links in JSP: The app loads, but CSS, images, or scripts point to the wrong folder.
- Stale browser or server cache: An old route or redirect is still being used.
In UK hosting environments, this is especially common when a site is moved from one release structure to another, or when a JSP application is deployed through a control panel feature rather than directly on the server filesystem.
How Tomcat decides the public URL
Tomcat maps each application to a context path. If your application is deployed as myapp.war, the default URL is usually /myapp. If it is deployed as the root application, it may be served from /. The browser path is therefore not based only on the folder where the files are stored, but on the context definition used by the servlet container.
Common examples include:
- WAR name determines URL:
shop.waroften becomes/shop. - Context file overrides name: A context configuration can point the app to a different path.
- Root deployment: A special setup may serve the app from the domain root.
- Reverse proxy mapping: Apache can present one URL while forwarding to another backend path.
In My App Server environments, this matters because the Tomcat instance is managed through the Plesk extension and can be started, stopped, or reconfigured without changing how the URL is mapped. The URL mapping still needs to match the application release structure.
Most common reasons the path is wrong after deployment
The WAR file name changed
If you upload a new WAR file with a different name, Tomcat may create a new context path. For example, replacing app.war with app-v2.war may expose the application at /app-v2 instead of /app.
Fix: Keep the WAR filename consistent if you want the same public URL, or update the context configuration to match the new name.
The application was deployed as an exploded folder
When you upload an unpacked application directory, the folder name often becomes the path. If the directory is named ROOT2, the application may load under /ROOT2, not the domain root.
Fix: Rename the folder to the intended context name or deploy it through the configured app server interface.
There is an old deployment still active
If the previous release was not removed cleanly, Tomcat can keep serving the old context. This is common after a manual upload, where both the old and new version exist in different folders.
Fix: Check for duplicate deployments and remove unused versions before restarting the service.
Apache is rewriting or proxying the URL
If Apache is in front of Tomcat, the public URL may be controlled by rewrite rules, ProxyPass directives, or alias settings. A small configuration error can cause the application to open from a different base path.
Fix: Review Apache virtual host rules, proxy mappings, and any rewrite conditions that target the JSP application.
Relative URLs inside JSP files are incorrect
Sometimes the application itself loads correctly, but its resources appear to come from the wrong path. This happens when JSP pages use relative links such as css/style.css instead of context-aware paths.
Fix: Use context-aware URL construction so links resolve correctly regardless of deployment path.
The context root was set manually
In some hosting setups, the application context is configured in Tomcat context XML or through a Plesk extension. If a custom context root was set, it can override the expected default path.
Fix: Check the application context settings in My App Server or the relevant Tomcat configuration.
How to check the actual path in a hosted JSP setup
To identify the source of the problem, compare the configured application path with the path you see in the browser.
- Open the application URL in the browser and note the exact path after the domain.
- Check the deployed WAR file name or application directory name.
- Review the Tomcat context configuration, if available.
- Inspect Apache proxy or rewrite rules if the site is behind a front-end web server.
- Confirm that only one active version of the app is deployed.
- Test both the expected URL and the actual URL to see where the mismatch starts.
If you use My App Server in Plesk, the service management screen is usually the best place to confirm whether Tomcat is running the deployment you expect. The Plesk control panel can help you verify the active service, restart it after changes, and reduce confusion caused by stale application instances.
Practical steps to correct the path
1. Confirm the expected context root
Decide what the public URL should be. For example:
https://example.co.uk/for the root applicationhttps://example.co.uk/shopfor a subpath deploymenthttps://example.co.uk/app1for a multi-application account
Once the target path is clear, make sure the deployment name and context settings point to that same path.
2. Match the WAR or folder name to the URL
If you want the app to open at /shop, deploying a file called shop.war is usually the simplest approach. If you want the root domain, use the correct root deployment method rather than relying on a random file name.
3. Remove old deployments before re-uploading
Before publishing a new release, remove previous build folders and old WAR files where appropriate. Leaving both in place can cause the app server to choose the wrong context or keep the old one active.
4. Restart the app server service
In managed hosting, changes to the deployment path may not take effect until the app server is restarted. If you use My App Server, check the service control options in Plesk and restart Tomcat after making changes to the deployment structure.
5. Verify Apache and proxy settings
If your site uses Apache in front of Tomcat, confirm that the frontend path matches the backend application path. Pay attention to:
- ProxyPass and ProxyPassReverse rules
- Redirects from
/to a subdirectory - Alias statements
- Rewrite conditions that remove or add path segments
6. Update JSP links to use the application context
Hard-coded URLs are a frequent cause of path problems. Instead of assuming the app is always at the domain root, generate links relative to the current context. This helps keep CSS, JavaScript, images, and internal links working after redeployments.
7. Clear caches and test in a private browser session
After fixing the deployment path, clear browser cache and test again. If a reverse proxy or CDN is used, refresh that cache too, because it may still point to the old path.
JSP path problems in Plesk and My App Server
In a hosting control panel environment, path issues often come from the deployment workflow rather than from JSP itself. With the My App Server extension, you can manage a private Tomcat or JVM within your hosting account, which is useful for JSP, servlet, and WAR-based applications. However, the application path still depends on how the service is configured and what is uploaded.
Useful checks in this setup include:
- Whether the correct Java version is selected for the application
- Whether the Tomcat instance is started and using the right deployment
- Whether the WAR file name matches the expected context
- Whether the service needs a restart after upload
- Whether an additional Apache layer is changing the public URL
This is one reason why deployment control matters in JSP hosting. A clean release process reduces the chance of path mismatches and helps keep the public URL stable.
Examples of common path mismatches
Example 1: Application should load from the domain root
You upload myapp.war, but the browser opens /myapp instead of the domain root. This usually means the app was not deployed as the root context.
Resolution: Deploy it as the root application or configure the context explicitly.
Example 2: Old path still works after a release
You publish a new version, but the old URL still serves the previous release. This often means the old context is still active or a proxy rule still points there.
Resolution: Remove the old deployment, restart Tomcat, and verify Apache rules.
Example 3: Static assets load from the wrong folder
The JSP page opens, but the stylesheet and images fail because they request files from a path that does not match the deployment context.
Resolution: Use context-aware resource paths in the JSP code.
How to prevent path issues in future releases
- Keep deployment names consistent between releases.
- Use one defined context root and document it.
- Remove unused WAR files and old exploded folders before deployment.
- Test the application after every Tomcat restart.
- Review Apache proxy and rewrite rules whenever the public path changes.
- Build JSP links and resource URLs relative to the application context.
- Use the same release process for staging and production so path behavior stays predictable.
For smaller and medium JSP applications, this approach is usually enough to keep Tomcat-based hosting stable and predictable. It also fits well with private JVM hosting in a shared account, where you want application-level control without operating a full enterprise Java platform.
FAQ
Why does Tomcat add a folder name to my URL?
Tomcat usually uses the WAR file name or application directory name as the context path. If your application is named store.war, the URL often becomes /store.
Can I run a JSP application from the domain root?
Yes, but it requires the correct root deployment setup. Simply renaming a folder is not always enough if the context is defined elsewhere.
Why does the app work from one URL but not another?
This often means one path is being routed correctly and another is still pointing to an old deployment, rewrite rule, or proxy target.
Does restarting Tomcat help with path changes?
Yes, especially after changing deployment names, removing old versions, or updating context configuration. A restart ensures Tomcat reloads the current application mapping.
Is this a JSP problem or a hosting configuration problem?
Usually it is a deployment or configuration issue rather than a JSP language issue. JSP pages themselves can contribute when they use hard-coded links, but the main cause is often the context root or proxy setup.
What should I check first in Plesk?
Start with the app server service status, then confirm the deployed application name, version, and context. If Apache is used in front of Tomcat, review the site routing as well.
Conclusion
A JSP application loading from the wrong path in the UK is usually caused by a context mismatch, a deployment naming issue, or a proxy rule that does not match the intended public URL. In a Tomcat-based hosting setup with My App Server, the fastest way to resolve the problem is to check the deployed application name, verify the context root, remove old versions, and confirm that Apache or Plesk is not rewriting the path unexpectedly.
With a consistent release process and context-aware JSP links, you can keep the public URL stable and avoid the most common path-related deployment issues.