If a Tomcat application is loading from the wrong path, the usual cause is a mismatch between the application’s context root, the deployment location, and the public URL that your hosting control panel or Apache/Tomcat setup is serving. In a managed hosting environment with Plesk and a Java hosting extension such as My App Server, this often happens when a WAR file is deployed under one name, but the browser is reaching a different context path, or when an Apache rule, reverse proxy setting, or old deployment artifact is still pointing to a previous location.
For Java hosting, Tomcat hosting, JSP hosting, and servlet hosting, the path that matters is not only the folder where files are stored. Tomcat also uses a context path to decide which application should answer a request. If that context path does not match the URL you are using, the application may appear to load from the wrong directory, serve an old version, or return a 404 while the files are present on disk.
Why Tomcat may load an application from the wrong path
Tomcat resolves requests by context. That context can come from the WAR file name, a deployed directory name, a context descriptor, or a custom mapping in the control panel. In a hosting platform, Apache may also sit in front of Tomcat and forward requests to the JVM, which adds another layer where paths can be rewritten or redirected.
The most common reasons are:
- The WAR file name does not match the desired context root.
- An older exploded application directory still exists in the deployment folder.
- A custom context descriptor points to a different path.
- Apache or the hosting control panel is forwarding the request to a different backend.
- The browser is using a bookmarked URL that points to an old application path.
- The application was redeployed, but Tomcat has cached the previous context.
- Multiple deployments exist with similar names, so Tomcat selects the one with the expected context first.
How Tomcat decides which path to use
Tomcat does not simply serve whatever is inside a folder. It uses a web application context root, usually based on the deployment name. For example, if you deploy app.war, Tomcat commonly exposes it as /app. If the file is called ROOT.war, the application may be served from the domain root, such as https://example.com/.
In a managed hosting setup, this behaviour may be controlled through:
- the WAR file name
- the deployed directory name
- the
context.xmlfile or equivalent context settings - My App Server service configuration in Plesk
- Apache proxy or rewrite rules
If any of these layers disagree, the application can load from the wrong path even though the deployment itself completed successfully.
Typical symptoms
You may be facing a path issue if you see one or more of the following:
- The application opens at an unexpected URL, such as
/oldappinstead of/newapp. - A different application appears when you visit the expected path.
- Static assets such as CSS, JavaScript, or images are missing after deployment.
- Links inside the app point to the wrong base URL.
- Changes in the WAR file do not appear after redeploy.
- Tomcat logs show the application starting correctly, but the browser still reaches another path.
- The application works on one URL and not on the public domain used by Apache.
Check the deployment name first
The first thing to verify is the name of the deployed application. In Tomcat, the deployment name often defines the context root. If you want your app at /shop, the WAR should usually be named shop.war, unless a custom context is configured.
Use this quick check:
- Open your hosting control panel.
- Go to the Java hosting or My App Server section.
- Find the installed Tomcat application.
- Check the current application name, context path, and deployment status.
- Compare that with the URL you are testing in the browser.
If the name and URL do not match, Tomcat may be doing exactly what it was configured to do. In that case, the fix is usually to rename the WAR, adjust the context, or update the public path mapping.
Look for old files in the web application directory
One of the most common causes of loading from the wrong path is leftover deployment data. Tomcat can keep an exploded application directory alongside the WAR file. If the old directory remains after a redeploy, Tomcat may continue serving files from that older location, especially if the service was not fully restarted.
Check for:
- an old exploded folder with the same application name
- duplicate WAR files with similar names
- temporary files created during deployment
- an old version of the application still present in the deployment tree
If your hosting plan gives you access to file management through Plesk, compare timestamps carefully. A fresh upload should normally show a recent modified time. If the old application directory is still there, remove it only if you are sure it is no longer required by the current deployment.
Check the context root in My App Server or Plesk
With ITA Java hosting and the My App Server extension, the application can be installed and managed from Plesk, including the Tomcat service and JVM settings. That makes it easier to control the application lifecycle, but it also means the context root can be configured outside the WAR file itself.
Review the following settings if available:
- application name
- context root
- document root or app root
- public URL
- service status
- Java version selected for the app
If the context root is set to /, the application may be intended to run as the main site. If it is set to something else, the browser must use that exact path. A mismatch here often looks like a path problem, when in reality the app is correctly deployed but reached through the wrong URL.
Verify Apache proxying and rewrite rules
In many hosting configurations, Apache handles the public domain and forwards requests to Tomcat or a private JVM. That is useful for performance and flexibility, but it also introduces path rewriting. A rule intended to send all requests to the Java app may accidentally send only part of the site, or may rewrite to an older application root.
Check whether the domain uses:
- ProxyPass or reverse proxy rules
- rewrite rules in .htaccess or Apache config
- a custom virtual host mapping
- a front-end path that differs from the Tomcat context path
If Apache points to a different backend path than Tomcat expects, the URL in the browser may appear correct while the actual application served is not. This is especially important for JSP hosting and servlet hosting where relative paths inside the application depend on the effective context root.
Why the browser can seem to use the wrong path
Sometimes the issue is not Tomcat but the browser or application links. Hardcoded absolute URLs, cached redirects, and old bookmarks can all send users to the wrong path.
Examples include:
- links hardcoded to
/oldapp - JavaScript building URLs from an outdated base path
- a cached redirect to the previous context
- session cookies tied to an old path
- browser cache showing stale pages after deployment
To test this properly, open the site in a private window or clear the browser cache. Then access the application directly using the full URL and compare the response with the expected context root.
Step-by-step troubleshooting checklist
1. Confirm the requested URL
Write down the exact URL you are trying to open. Compare the domain and path carefully. A difference of even one character in the context root can lead to a completely different deployment.
2. Check the deployed application name
Find the WAR file name or application alias in My App Server. Make sure it matches the desired public path.
3. Remove outdated duplicates
Look for previous WAR files, exploded folders, or temporary deployment data that may still be active.
4. Restart the Tomcat service
From the service control section in Plesk, restart the Java service or Tomcat instance after changes. This helps Tomcat release cached contexts and reread deployment settings.
5. Review Apache forwarding
Confirm that the public domain is forwarding to the correct backend and that no rewrite rule points to an older application root.
6. Check application logs
Review the Tomcat logs for deployment messages, context warnings, or errors related to duplicate applications, invalid paths, or failed resource loading.
7. Test the app directly
If your setup allows it, access the application using the direct Tomcat context path and compare that result with the public domain through Apache. This helps identify whether the issue is in Tomcat or in the front-end routing layer.
Common fixes for wrong Tomcat paths
Depending on the cause, one of these fixes usually resolves the issue:
- Rename the WAR file to match the required context root.
- Delete old exploded application folders before redeploying.
- Update the context configuration in Plesk or My App Server.
- Restart the Tomcat service after deployment.
- Correct Apache proxy rules or rewrite conditions.
- Update application links to use the current base path.
- Clear browser cache and test again.
If you are deploying a root application, make sure there is only one ROOT mapping in use. If another site or old deployment already uses that path, Tomcat may serve the wrong application from the domain root.
Examples of path mismatch scenarios
WAR name and URL do not match
You upload crm.war, but expect the app to open at /sales. Tomcat will normally expose it as /crm unless you rename the file or define a custom context. The fix is to align the WAR name or context root with the desired URL.
Old version still appears after redeploy
You replace the WAR file, but the browser still shows the old layout. In many cases, an exploded folder or cached Tomcat context is still active. Remove leftovers, restart the service, and test again.
Public domain points to the wrong backend
Your Tomcat app works on its internal path, but the public URL shows another site. This usually means Apache virtual host configuration or proxy mapping is sending traffic to the wrong application.
Best practices to avoid path issues in Tomcat hosting
- Use consistent naming for WAR files and application folders.
- Document the intended public URL for each Java application.
- After every deploy, verify the active context root.
- Keep only one live deployment for each context path.
- Restart the service after structural changes, not only after file uploads.
- Avoid hardcoded URLs inside the application when possible.
- Test from a private browser session after major release updates.
These habits are especially helpful in shared hosting environments where one account can run a private JVM, a custom Tomcat, and Apache routing at the same time. Clear naming and a predictable release workflow reduce the chance of path confusion.
When to contact hosting support
Contact support if you have already checked the deployment name, removed duplicates, restarted the service, and verified Apache settings, but the application still loads from the wrong path. Provide the following details:
- the domain name
- the exact URL that fails
- the intended context path
- the deployed WAR name
- the Tomcat or My App Server version
- relevant log messages or screenshots
This information helps support identify whether the issue is in the Tomcat deployment, the Plesk configuration, the Apache front end, or a stale application context.
FAQ
Why does Tomcat use a different path than my file name?
Tomcat often uses the file name as the context root, but custom context settings or hosting control panel configuration can override that. The deployed name and the public URL may not always be identical.
Can I make a Tomcat app load from the domain root?
Yes, usually by deploying it as ROOT.war or by setting the context root to / in the hosting panel or context configuration. Make sure no other application is using the same root path.
Why does the app still load the old path after redeploy?
Most often because an old deployment folder, cached context, or Apache rewrite rule is still active. Restart the service and check for duplicate files or stale proxy settings.
Is this a problem with Java version or JVM settings?
Usually no. Java version problems can break startup, but a wrong path is more often a context or routing issue. Still, confirm that the selected Java version matches the application requirements.
Do I need enterprise Tomcat features to fix this?
No. In most hosting environments, correct context naming, clean deployment, and proper Apache or Plesk mapping are enough. This is a practical Tomcat hosting issue, not an enterprise cluster requirement.
Conclusion
When a Tomcat application loads from the wrong path, the root cause is usually a mismatch between deployment name, context root, and public URL mapping. In a hosted Java environment with Plesk and My App Server, the fix is typically straightforward: verify the WAR name, remove old deployment data, check the context root, restart the Tomcat service, and confirm that Apache is forwarding requests to the correct backend path.
For Java hosting and Tomcat hosting, a clean path structure is just as important as the application code itself. Keeping deployment names consistent and reviewing routing after every release will prevent most path-related issues and make future updates safer.