If a JSP application loads from the wrong path, the cause is usually one of three things: the context root is different from the path you expected, the application was deployed under a different name, or Tomcat/Apache is forwarding requests in a way that changes the visible URL. In a managed hosting environment with Plesk, My App Server, and a private Tomcat instance, this is common when the app is uploaded as a WAR, installed with a custom context, or moved between releases.
The good news is that the issue is usually easy to trace. In most cases, the application is working correctly, but the public URL, deployment path, or document root does not match the path used in the browser or in your links.
Why a JSP application may open from the wrong URL path
A JSP application does not always run from the same path where its files are stored on the server. On Java hosting platforms, the browser path is determined by the web application context, not by the internal file system path. That means the app may be deployed in Tomcat under a context such as /app, while the source files or WAR file live somewhere else inside the hosting account.
In Plesk-based Java hosting, this distinction matters even more because the deployment can be managed through an extension like My App Server. The control panel may create the Tomcat application automatically, assign a context root, and then expose it through Apache or a proxy URL. If any of those parts are changed, the app may appear to load from the wrong place.
Most common causes
1. The context root does not match the URL you are using
The context root is the first part of the web app path after the domain. For example, if your app is deployed as /shop, then the public URL is usually https://example.com/shop/. If you try to open / or /index.jsp directly, the app may not behave as expected.
In Tomcat, context roots are often derived from the WAR filename or from the deployment configuration. For example:
- shop.war typically becomes /shop
- ROOT.war typically becomes the main site at /
- a manually configured context file may use a different path
2. The app was deployed under a different application name
If you upload a WAR file with one name and later rename it, Tomcat may deploy it under the new name. That changes the public path. A file called myapp-v2.war is not the same as myapp.war from the perspective of the context path.
This is one of the most frequent reasons why a JSP application seems to “move” after a new release.
3. You are seeing Apache instead of Tomcat content
In a hosting platform that combines Apache and Tomcat, Apache may serve static content, while Tomcat handles the JSP application. If Apache is configured to serve a different directory, or if a rewrite rule is sending traffic elsewhere, the URL in the browser may not point to the Tomcat app you expected.
This can happen when:
- the domain document root is set to another directory
- there is an .htaccess rule redirecting requests
- a proxy or connector forwards only some paths to Tomcat
- an old release is still active in the Apache-facing path
4. The wrong WAR or directory is still active
After deployment, the old version may still be present in the Tomcat webapps directory, or the application may not have been redeployed cleanly. This can cause the server to keep serving an older context path or an outdated exploded directory.
In managed hosting, this often happens after:
- uploading a new WAR without removing the previous one
- changing the app name but leaving old files behind
- restarting the service before the deploy is complete
5. Links inside the JSP app use absolute paths
Sometimes the page itself loads correctly, but resources such as CSS, images, JavaScript or internal links point to the wrong path. This is usually caused by hardcoded absolute URLs like /images/logo.png or /login when the app is not deployed at the site root.
If the application is installed at /portal, then a link to /images/logo.png points to the domain root, not to /portal/images/logo.png.
6. Reverse proxy or rewrite settings change the visible path
If your hosting setup uses Apache as a front end and Tomcat as the app server, the visible URL may be rewritten before the request reaches the Java app. This is useful for clean URLs, but it can also hide the real deployment path and make debugging harder.
Common examples include:
- redirecting /app to /app/
- rewriting / to a subdirectory
- mapping a friendly domain path to a Tomcat context
How to check the real deployment path in Plesk and Tomcat
Step 1: Confirm the deployed application name
Open your hosting control panel and check the app name in My App Server or the Java application list. The deployed application name is often the same as the context root. If the app is shown as crm, then the public path is likely /crm.
If you use a WAR file, check its filename as well. A renamed WAR may deploy to a different path even if the code inside is unchanged.
Step 2: Compare the browser URL with the context root
Look carefully at the browser address bar. The domain alone does not tell you the whole story. Check whether the app is expected to open at:
- / for the main site
- /app for a sub-path application
- /app/ for a directory-style context
- a custom mapped URL defined by Apache or Plesk
If the app opens only when you add a specific suffix, then that suffix is probably the true context path.
Step 3: Check whether the app is deployed as ROOT
If you want the JSP application to load from the main domain path, it usually needs to be deployed as the ROOT application. In Tomcat, that often means using ROOT.war or a root context configuration.
Be careful here. If another website or application is already using the domain root, deploying a new ROOT app may hide the previous content.
Step 4: Inspect Apache rewrite rules
If the application is behind Apache, review any rewrite or redirect rules in .htaccess or the Apache virtual host configuration available through your hosting environment. A rule intended for SEO-friendly URLs can accidentally send traffic to the wrong location.
Look for:
- redirect loops
- rules that strip or add a path segment
- forwarding to the wrong directory
- old rewrite rules left behind after a release
Step 5: Verify static resource paths in JSP pages
If only images, scripts, or CSS files are missing, the deployment path may be correct but the app code may be using the wrong resource paths. In JSP, this is often caused by hardcoded links rather than context-aware links.
Use context-relative paths in your pages and templates so the app works whether it is deployed at the root or in a subdirectory.
How to fix a JSP app loading from the wrong path
Fix 1: Deploy with the intended context root
Make sure the app is deployed using the name you actually want in production. If the application should open at /portal, deploy it as portal.war or set the context accordingly in your Tomcat setup.
In a Plesk environment with My App Server, this usually means checking the application installation settings before uploading the release.
Fix 2: Remove old deployments before uploading a new one
Before releasing a new build, remove the old WAR and any exploded application directory that belongs to the same app. This avoids stale context mappings and prevents Tomcat from mixing files from different versions.
As a safe release practice, keep only one active copy of the application unless you intentionally use versioned paths.
Fix 3: Use context-aware links in JSP
Do not hardcode absolute paths unless the app is always guaranteed to live at the domain root. Instead, build links relative to the context root. This helps prevent broken navigation after redeploys or path changes.
Typical symptoms of hardcoded paths include:
- home page loads, but menu links 404
- CSS or JS is missing after moving the app
- images work in one environment but fail in another
Fix 4: Check proxy and Apache configuration
If Apache is involved, confirm that it is pointing to the correct Tomcat application and not another folder or outdated site configuration. If your hosting plan allows custom Apache settings, review any virtual host directives that map the domain to a backend path.
In managed hosting, it is often safer to keep proxy rules simple and let the control panel manage the Tomcat route where possible.
Fix 5: Redeploy and restart the Java service
After correcting the context path or deployment files, redeploy the application and restart the Java service from the control panel if needed. A restart can clear stale class loading, old context references, and cached deployments.
With My App Server, service control is usually available from Plesk, which makes it easier to apply the changes without direct server access.
Example scenarios
Scenario 1: The app should open at the domain root, but it loads at /shop
This usually means the app was deployed as shop instead of ROOT. Rename the WAR or update the context so the application becomes the root application.
Scenario 2: The login page works, but images return 404
The JSP pages likely use absolute resource paths that do not include the application context. Adjust the links to be context-relative.
Scenario 3: After uploading a new WAR, the old path still appears
An old deployment may still be active, or Tomcat may have retained an exploded copy. Remove the previous app version, clear the old directory, and redeploy cleanly.
Scenario 4: The domain opens an Apache page, not the JSP app
The Apache document root may still point to a static directory or another site. Check the domain mapping and ensure the request is routed to the Tomcat application.
Best practices for JSP hosting path management
- Choose a clear application name before deployment.
- Keep WAR filenames consistent across releases.
- Use context-relative links in JSP pages and templates.
- Remove old releases before uploading new ones.
- Check Apache rewrite rules after each deployment change.
- Use the hosting control panel to confirm the active Java service and app path.
- Test both the main page and static assets after every release.
These practices are especially useful on shared Java hosting platforms where you manage a private JVM or Tomcat instance through a control panel rather than a full enterprise deployment stack.
How My App Server helps with path-related issues
In an ITA Java hosting setup, My App Server gives you a practical way to run JSP and servlet applications inside a private Tomcat environment without having to manage a separate physical server. That makes it easier to review the application context, control the service, and select the right Java version for the app.
For path issues, the main advantage is visibility. You can more easily check:
- which app is installed
- which service is running
- which Java version is assigned
- which release is active
- how the public URL maps to the Tomcat context
This is particularly useful when a JSP app behaves differently after a new deployment or when you move from a local test environment to managed hosting.
When the problem is not the path
Sometimes the app looks like it is loading from the wrong path, but the real issue is different. Before changing the deployment, check whether the problem is actually one of these:
- session cookies are not set for the correct domain or path
- the app redirects to a login page after the first request
- the browser caches an old redirect
- a front-end script is building incorrect URLs
- the application throws an exception and falls back to an error page
If the URL changes unexpectedly after a redirect, the problem may be in the application code or rewrite rules rather than the deployment path itself.
FAQ
Why does Tomcat deploy my JSP app under a different path?
Tomcat often uses the WAR filename or deployment context name to create the public path. If the file is named app.war, the context is usually /app. If you rename the file, the path can change too.
Can I make a JSP app load from the domain root?
Yes. In Tomcat, this is usually done by deploying the app as ROOT. In a hosting control panel, you may need to update the application name or deployment settings so the root URL points to the correct app.
Why do images and CSS break after I move the app?
That usually happens because the JSP pages use hardcoded absolute paths. When the app moves to a new context, those paths no longer point to the right files.
Do I need Apache for JSP hosting?
Not always, but many hosting setups use Apache in front of Tomcat for routing and static file handling. If Apache is involved, its rewrite rules and document root can affect which path the browser sees.
Should I delete the old WAR before deploying a new release?
Yes, in most cases. Removing the previous WAR and any exploded directory helps prevent stale paths, old code, and mixed deployment states.
Can My App Server run a private Tomcat instance for JSP apps?
Yes. The Java hosting setup is designed for running a private Tomcat or JVM inside a hosting account, which is practical for JSP, servlet, and smaller Java web applications.
Conclusion
If a JSP application loads from the wrong path, start by checking the context root, the WAR filename, and any Apache rewrite rules. In a managed hosting environment with Plesk and My App Server, the visible URL may differ from the internal deployment path, so the issue is often configuration rather than application failure.
For the fastest fix, confirm the active application name, remove old deployments, verify the public URL, and make sure your JSP links are context-aware. Once the deployment path and the browser path match, the application should load consistently across releases.