When a Java application loads from the wrong path, the root cause is usually not Java itself, but the way the application is deployed, the context root is mapped, or the web server and application server are resolving files differently than expected. In a hosting environment with Plesk, Apache, and a private Tomcat instance, this can happen after an update, a change in deployment structure, or a mismatch between the public URL and the application’s internal file paths.
For Java hosting, Tomcat hosting, JSP hosting, and servlet hosting, the most common issue is that the application is being served from one directory while requests, static resources, or redirects still point to another. This is especially visible when a WAR file is redeployed, when the context path changes, or when the app uses hardcoded paths instead of relative paths or container-aware configuration.
Why Java applications load from the wrong path
A Java web application can appear to load from the wrong path for several reasons:
- The context root does not match the public URL.
- The application was deployed under a different name than expected.
- Static files are referenced with absolute paths that do not fit the hosting setup.
- Apache, Plesk, or Tomcat rewrites or forwards requests to another location.
- The application cache, browser cache, or server cache still points to the old deployment.
- The app is using a custom base path, but the deployment or reverse mapping was not updated.
In managed hosting, the web path that users see in the browser is often not the same as the physical path on disk. The application may run inside a private JVM or Tomcat service, while Apache handles the public domain and forwards requests to the Java process. That means the visible path, the Tomcat context path, and the filesystem path must all align.
Path types you need to distinguish
To troubleshoot correctly, it helps to separate the different path layers used in Java hosting.
1. Filesystem path
This is the physical location on the server where the application files are stored, such as the deployed WAR, exploded webapp, JSP files, or static assets. This path is visible in Plesk or within the hosting account file manager.
2. Context path
This is the URL segment that Tomcat uses to expose the application. For example, if the app is deployed as myapp.war, the default context path may become /myapp. If you want a different public URL, the context must be configured accordingly.
3. Public URL path
This is the address the user opens in the browser, such as https://example.com/app/. In a hosting control panel, this may be managed by Apache, a proxy mapping, or the My App Server extension, which connects the public domain to the Java service.
4. Resource path inside the application
These are references to CSS, images, JS, JSP includes, and internal links. If these paths are hardcoded incorrectly, pages may load from the wrong directory even when the application itself starts correctly.
Most common causes in Plesk and Tomcat hosting
WAR file name defines the context
In Tomcat, the deployed WAR file name often becomes the context path. For example:
app.war→/appROOT.war→ the site root domain
If the application expects to run at the domain root but is deployed as /app, links and resource loading may break. The reverse is also true: an app built for /app may fail if it is suddenly deployed as the root application.
Old deployment artifacts remain on the server
Sometimes an older exploded directory, temporary file, or previous WAR version remains in the deployment area. Tomcat may load the stale version first, especially if the old context is still present. This can make it look like the app is loading from the wrong path when in fact Tomcat is using an older deployment.
Hardcoded absolute paths in code
Applications that use absolute links like /images/logo.png or /app/css/main.css may fail when the context changes. This is common after moving from local development to hosting, or after changing the deployment directory in My App Server.
Apache forwards to Tomcat but does not match the app path
In many hosting setups, Apache serves the public domain and proxies requests to a Java service. If the proxy rules or alias settings do not match the Tomcat context path, the browser may request one path while the application expects another. The result can be missing pages, broken assets, or redirects to the wrong location.
Application uses cached base URLs
Some Java frameworks store the base path, generated URLs, or redirect targets in configuration files or session data. If the app was moved, renamed, or deployed under a new context, these stored values can continue to point to the old path.
How to check what path the application is actually using
Before changing anything, confirm where the application is loading from. In a hosting environment, you can usually check this from both Plesk and the application itself.
Check the deployed application name
Open the hosting file manager or deployment directory and verify the WAR file name and folder structure. If the app is named differently from the expected URL, Tomcat may expose it under a different context path.
Check the service configuration in My App Server
If you are using ITA’s My App Server extension, review the service settings in Plesk. Confirm:
- which Tomcat or private JVM service is assigned to the domain,
- which Java version is selected,
- which deployment directory is used,
- whether the app is deployed as the root application or under a subpath.
This is important because the same hosting account can contain multiple Java applications, and each one may have its own service or context mapping.
Check browser developer tools
Open the browser network panel and look at failing requests. If CSS, images, or API calls are being requested from the wrong path, the issue is often inside the application templates rather than in Tomcat itself.
Check Tomcat logs
Tomcat logs can show which context was deployed, whether an older version was reused, and whether the application started from the expected location. If a deployment failed, Tomcat may fall back to the previous app or leave a partially updated context active.
How to fix a Java app that loads from the wrong path
1. Verify the intended public URL
First decide where the application should be reachable:
- at the domain root, such as
https://example.com/, or - under a subpath, such as
https://example.com/app/.
That decision determines how the WAR should be named and how the Tomcat context should be configured.
2. Match the deployment name to the required context
If the app should open at the root domain, deploy it as ROOT.war or configure the root context in the hosting panel if that option is available. If it should run under a subpath, ensure the deployed name and context mapping match that subpath.
In a managed hosting panel, this often means re-checking the My App Server deployment profile rather than only uploading files.
3. Remove stale deployments before redeploying
Delete the old WAR, the exploded application directory, and any cached deployment artifacts if the panel exposes them. Then upload the new build cleanly. This reduces the chance that Tomcat keeps serving a previous version from the wrong location.
4. Replace hardcoded paths with relative or context-aware paths
Use relative links where possible. In JSP and servlet applications, build resource links based on the current context rather than fixed absolute paths. This is especially important if the app may be moved between a root deployment and a subdirectory deployment.
Examples of safer approaches include:
- relative asset references for local page resources,
- framework helpers that generate context-aware URLs,
- server-side functions that read the application context path dynamically.
5. Review Apache or proxy mappings
If Apache is proxying requests to Tomcat, ensure the public path and backend path match. A domain root request should not be forwarded to an unexpected backend subpath unless that mapping is deliberate and documented. If there is an alias, rewrite, or proxy rule, verify that it sends requests to the same context that the Java app is using.
6. Clear caches
After fixing the deployment, clear:
- browser cache,
- application cache,
- reverse proxy cache if present,
- Tomcat temporary deployment data if the panel provides that option.
Old cached redirects and asset references are a frequent reason why a corrected deployment still appears to load from the wrong path.
7. Restart the Java service if needed
In hosting environments that provide a private JVM or Tomcat service, restart the service after changing the deployment structure or context mapping. This ensures the runtime reloads the current configuration and does not keep an old webapp instance in memory.
How this behaves in My App Server
With ITA’s My App Server, you can manage a Java application inside your hosting account without handling the whole server manually. That makes path issues easier to diagnose because the service, Java version, and deployment can be viewed from the control panel.
Typical benefits in this scenario include:
- control over the Tomcat or private JVM service from Plesk,
- selection of an appropriate Java version,
- deployment of WAR-based applications, JSP sites, and servlet applications,
- separation between the public web path and the internal runtime path,
- easier redeploy and service restart when a path mismatch occurs.
If the app loads from the wrong path after a release, the most practical approach is to confirm the deployed context, check the service assignment, and validate whether Apache or Tomcat is serving the expected version.
Examples of path mismatch and the correct fix
Example 1: App should open on the domain root, but loads under /app
Symptom: Users must open /app instead of the main domain.
Likely cause: The WAR file is named app.war instead of ROOT.war, or the root context was not configured.
Fix: Deploy as ROOT.war or configure the application as the root context in the hosting panel.
Example 2: Images and CSS load from the wrong folder
Symptom: The page loads, but styling and images are broken.
Likely cause: The app uses absolute links that still point to the old context or file structure.
Fix: Convert resource references to context-aware or relative paths, then redeploy.
Example 3: Old version still appears after deployment
Symptom: The new WAR was uploaded, but the site still shows old behaviour.
Likely cause: A stale exploded directory or cached context is still active.
Fix: Remove the previous deployment, restart the service, and redeploy cleanly.
Example 4: Apache redirects to the wrong backend path
Symptom: The public URL redirects oddly or shows a backend-specific path.
Likely cause: The Apache proxy or rewrite rule does not match the Tomcat context.
Fix: Review the forwarding rule and align it with the actual Java application context.
Best practices to avoid wrong-path issues
- Keep deployment names stable between releases.
- Use the same context path in development and hosting whenever possible.
- Avoid hardcoded absolute URLs inside JSPs, servlets, and templates.
- Deploy cleanly instead of overwriting files manually on top of an old version.
- Check Apache, Tomcat, and Plesk mappings after every structural change.
- Restart the Java service after context changes or major releases.
- Document whether the app is intended to run at the root domain or under a subpath.
These steps are especially useful for smaller and medium Java applications hosted on a private Tomcat or JVM service where deployment is managed through a hosting control panel rather than a full application platform.
When the issue is in the application code
Not every wrong-path problem is caused by the hosting setup. Sometimes the Java application itself generates incorrect links, redirects, or resource paths. This is common if the app:
- builds URLs by concatenating strings manually,
- assumes the app always runs at the domain root,
- stores path values in configuration without updating them after deploy,
- mixes filesystem paths with public URL paths.
If the deployment is correct but the app still opens the wrong location, inspect the code that creates links, forwards requests, or reads base-path settings. In JSP and servlet applications, using context-aware helpers is usually the most reliable fix.
FAQ
Why does Tomcat use a different path than the domain name?
Tomcat exposes applications through a context path, which may come from the WAR file name or a configured mapping. The domain name is only the public address; it does not automatically define the application context.
Can I make a Java app load from the site root?
Yes. In many hosting setups, this is done by deploying the application as ROOT.war or by assigning the root context through the control panel or Tomcat configuration.
Why do my static files load from the old path after redeploy?
This is often caused by cached assets, old deployment files, or hardcoded URLs in the application templates. Clear caches and confirm that the resource paths are context-aware.
Does Plesk control the Java path or Tomcat does?
Both can be involved. Plesk or the hosting extension manages the service, deployment, and mappings, while Tomcat determines the actual application context. The final public path depends on how they are connected.
What should I check first if my app suddenly loads from the wrong folder?
Start with the WAR name, deployed context, and any recent changes to Apache proxy rules or Plesk service settings. These are the most common causes after a release.
Conclusion
A Java application loading from the wrong path is usually a deployment or context mapping problem, not a Java runtime failure. In hosting environments with Plesk, Apache, and a private Tomcat service, the key is to align the filesystem location, the Tomcat context root, and the public URL path. Once those three layers match, the application usually loads correctly.
If you are using My App Server, the fastest resolution is to verify the deployment name, confirm the service assignment, check for stale files, and review any path-related settings in the control panel. For most Java hosting and Tomcat hosting cases, a clean redeploy with correct context mapping solves the problem.