When a Java application loads from the wrong path, the cause is usually not the application itself but the way the web container, virtual host, context root, or public URL is mapped in the hosting control panel. In a Plesk-based Java hosting setup with My App Server, this often happens when a Tomcat application is deployed under one path, while the domain, subdomain, or browser URL points to another.
On shared Java hosting, the expected behaviour is simple: your public URL should map cleanly to the correct app context, and the app should resolve static files, JSP pages, servlets, and redirects relative to that context. If the application opens from an unexpected directory, returns the wrong page, or shows broken links after deployment, the issue is usually related to context path configuration, deployment structure, or a mismatch between Apache, Tomcat, and the public document root.
Common reasons a Java app loads from the wrong path
In most cases, the problem comes from one of the following:
- The WAR file name does not match the expected context root.
- The application was deployed into the wrong Tomcat webapps directory.
- Apache is forwarding the request to a different backend path than intended.
- The domain or subdomain is pointing to a different document root.
- The application uses relative links that assume a different base path.
- The app was tested on a temporary URL, but the live domain uses another context.
- A cached redirect or browser cache is still sending traffic to the old location.
In managed hosting environments, especially when using a private JVM or private Tomcat instance through Plesk, the path must be consistent across three layers:
- the public URL seen by the visitor,
- the Apache or proxy mapping,
- the Tomcat application context.
If any one of these layers is different, the application may appear to load from the wrong path.
How context roots work in Tomcat hosting
Tomcat uses a context root to decide which URL path serves which application. For example, if an app is deployed as /shop, then the public URL may be something like https://example.co.uk/shop/. If the app is deployed as the root application, it may load from /.
With Java hosting on My App Server, the context root is important because it determines where Tomcat expects the application to live. If the context name and the public URL do not match, users can see one of these symptoms:
- the homepage loads, but internal pages return 404 errors;
- CSS, images, or JavaScript files fail to load;
- links point to the wrong subfolder;
- the app opens on an unexpected URL after login;
- one deployed version overrides another version unexpectedly.
In many Java web apps, the context root is set by one of the following:
- the WAR file name;
- a context descriptor;
- a Plesk or control panel deployment setting;
- a reverse proxy or Apache rewrite rule.
If you are using a custom Tomcat instance in your hosting account, make sure the deployment path matches the intended public path before going live.
Why the wrong path often appears after deployment
1. WAR file name does not match the desired URL
Tomcat commonly uses the WAR file name as the application context. If you upload myapp.war, the app may deploy to /myapp. If you expected the site to open at the domain root, it will instead load from a subpath.
Example:
- Uploaded file: shop.war
- Deployed path: /shop
- Public URL: https://yourdomain.co.uk/shop/
If the application is meant to be the main site, deploy it as the root context rather than as a named folder, or update the mapping accordingly.
2. App was deployed into the wrong directory
On a shared hosting account with a private Tomcat instance, the app may be uploaded to a folder that is not the one Tomcat is currently using. This can happen if there are multiple versions, temporary staging folders, or manual uploads outside the expected service directory.
Check that the application files are placed in the actual deployment location used by the My App Server service. If the service was restarted after an upload, confirm that the correct app archive or exploded directory is the one Tomcat loads at startup.
3. Apache and Tomcat point to different paths
In many hosting setups, Apache handles the public request and forwards it to Tomcat. If Apache is configured with a different document root, alias, or rewrite target, the visitor may reach a path that does not match the Tomcat context.
Typical signs include:
- the browser URL says one path, but the app acts as if it were in another;
- redirects send users to a missing directory;
- static resources load from the wrong base URL;
- the app works directly on one path but not through the domain.
In a Plesk environment, make sure the domain’s public directory, Apache settings, and the Java service routing are aligned.
4. Relative links are built against the wrong base path
Java applications sometimes use relative URLs for CSS, images, forms, and servlet calls. If the app is moved from one context to another, those links may still point to the old location.
For example, an app originally developed under /app may still generate links like:
- /app/css/style.css
- /app/login
- /app/api/status
If the app is later deployed at the domain root, those paths may no longer be valid. The result is that the page loads, but some parts come from the wrong location or fail completely.
5. Cached redirects or browser cache
Sometimes the application path is correct, but the browser continues to use an old redirect, especially after a move from staging to production or after a context change. This is common when the app previously lived under a different folder and now has a new public URL.
Check the issue in:
- an incognito/private browser window;
- a different browser;
- a cleared cache session;
- server-side logs, if available.
How to check the correct path in a Plesk Java hosting setup
If you use My App Server for Java hosting, follow these checks in order:
1. Confirm the domain or subdomain
Make sure you are opening the correct hostname. In hosting control panels, the same account can contain multiple domains, subdomains, and aliases. If you test on one hostname but expect another, the app may appear to load from the wrong path.
Check:
- domain name spelling;
- subdomain vs main domain;
- alias or parked domain behaviour;
- HTTPS vs HTTP redirects.
2. Verify the Java app context in My App Server
Open the service settings and confirm which context the application is assigned to. If the app is set to /demo, then the browser must use that path unless you intentionally map it to the root.
If you uploaded a WAR file with a different name, remember that Tomcat may use that name as the default context unless you override it.
3. Check the deployment folder and file naming
Review whether the application is deployed as:
- a WAR archive;
- an exploded directory;
- a manually installed Tomcat webapp;
- a custom app server setup.
A mismatch between the file name and the expected route is a very common reason for path-related issues.
4. Review the application’s base URL configuration
Some Java applications have a setting for public base URL, context path, or server prefix. If this value is left from a staging environment, the app may generate links to the wrong folder.
Check for values such as:
- base URL;
- server URL;
- context path;
- application root;
- redirect URL.
When possible, configure the app to build URLs dynamically from the request context rather than hardcoding a path.
5. Restart the service after changing paths
When you change the deployment path or context mapping, restart the Java service in the control panel so Tomcat reloads the correct configuration. In managed hosting, a restart often clears stale context information and ensures the new route is applied.
Practical steps to fix a Java application loading from the wrong path
Use this checklist to resolve the issue methodically:
- Identify the URL you expect the app to use.
- Compare that URL with the actual browser address bar.
- Check whether the WAR file name matches the intended context.
- Verify that the app is deployed in the correct Tomcat service.
- Confirm that Apache or proxy routing does not rewrite the path unexpectedly.
- Inspect application logs for 404s, redirect loops, or failed resource requests.
- Clear browser cache and test in a private window.
- Restart the My App Server service after any context change.
If the application still loads from the wrong path, temporarily test it with a simple root page or a minimal JSP file. This helps separate a deployment mapping issue from an application-level routing issue.
Examples of path mismatches
Example 1: WAR file deployed as a subpath
You upload portal.war and expect the app to open at the domain root. Tomcat deploys it under /portal, so the correct URL becomes https://example.co.uk/portal/. If you open only https://example.co.uk/, you will see the default site or an empty page instead.
Example 2: App built for /app but moved to root
A JSP application was originally developed for /app. It contains links like /app/login and /app/assets/main.css. After deployment to the root context, those links no longer point to the correct files. The homepage may load, but styles and navigation fail.
Example 3: Domain points to the wrong service
The hosting account has two Java services: one for testing and one for production. The domain is attached to the test service, while the live app is in the production service. The result is that the public site loads the wrong content and path.
How to prevent path problems in future deployments
Good deployment habits reduce path errors and make Java hosting easier to manage:
- Use consistent WAR naming conventions.
- Document the intended context root before deployment.
- Keep staging and production URLs separate and clearly labeled.
- Avoid hardcoded absolute paths inside JSP, servlet, or frontend code.
- Use request-aware URL building for links and assets.
- Review control panel settings after every release.
- Restart the Java service when changing deployment structure.
For applications hosted with My App Server, these steps are especially useful because the service is designed for practical control over Java runtime, Tomcat version, and deployment path inside a shared hosting account.
When to check logs and service settings
If the wrong-path issue is not obvious, logs can help you see whether Tomcat is loading the expected context or whether Apache is sending requests elsewhere. Look for:
- 404 Not Found responses for static resources;
- redirects to old folders;
- startup messages showing a different context name;
- errors related to missing JSPs or servlets;
- duplicate deployments of the same application.
Also check the service status and configuration in the control panel. In a managed hosting environment, a service may be running correctly but still use an outdated deployment path after a release change.
FAQ
Why does my Java app work on one URL but not on another?
Because the application context, Apache routing, or domain mapping is not the same for both URLs. The app may be deployed under a specific path and only work when that exact path is used.
Does the WAR file name affect the public URL?
Yes, in many Tomcat setups the WAR file name becomes the default context root. If you want a different public path, rename the archive or change the context mapping.
Why are CSS and images loading from the wrong place?
This usually means the application uses relative or hardcoded paths that no longer match the deployed context. Update the base URL or use context-aware links.
Can Apache cause a Java app to load from the wrong path?
Yes. If Apache rewrite rules, proxy settings, or document roots point to another location, the browser may reach a different path than the one Tomcat expects.
Should I restart Tomcat after changing the path?
Yes. After changing context or deployment settings, restart the service so the new mapping is loaded cleanly.
Is this usually an application bug?
Not always. In hosting environments, wrong-path issues are often caused by deployment configuration rather than by the Java code itself.
Conclusion
If a Java application is loading from the wrong path, the most likely cause is a mismatch between the public URL, the Tomcat context root, and the deployment settings in your hosting control panel. In a Plesk-based Java hosting setup with My App Server, this is usually resolved by checking the WAR name, deployment directory, domain mapping, Apache routing, and application base URL configuration.
Once the path is aligned across the control panel, Apache, and Tomcat, the application should load consistently from the correct location and its internal links, JSP pages, and servlet routes should behave as expected.