If a Java website starts showing the wrong path, an unexpected 404 Not Found, or links that appear to point to the wrong place, the issue is usually not the Java code alone. In hosting environments, the problem often comes from a mismatch between the application path, the Tomcat context, the Apache proxy configuration, the deployed WAR file, or the way the app is started inside Plesk.
In a managed Java hosting setup such as My App Server, you typically run your own Apache Tomcat or private JVM inside a hosting account. That gives you flexibility, but it also means the visible URL path must match the application’s deployment path, servlet mappings, and any Apache or proxy rules in front of it. When those parts are not aligned, the browser may load the wrong application path, or Tomcat may return a 404 even though the app is running.
Why this happens
A Java app can return a wrong path or a 404 for several different reasons. The most common are:
- The application is deployed to a different context path than the one used in the browser.
- The WAR file name changed, which changed the Tomcat context path.
- The app expects to run at
/, but it is actually deployed under a subpath. - Apache or a reverse proxy is rewriting the URL incorrectly.
- Servlet mappings or JSP paths are incorrect inside the application.
- The application references absolute links that do not match the deployed path.
- The service did not start correctly, so the path exists in configuration but not in the running JVM.
In other words, the browser path, the Apache path, and the Tomcat context path must all agree. If one of them is off, you may see 404 errors, broken links, redirects to the wrong location, or pages loading partly and then failing.
Most common symptoms
Before changing anything, identify the exact behavior. That makes troubleshooting much faster.
The browser shows a 404 on the main URL
This often means the app is not deployed to the path you are using, or the Tomcat context has changed. It can also mean the service is stopped or the WAR deployment failed.
Links inside the app point to the wrong location
This usually happens when the app was built with hardcoded paths such as /app or /myapp, but it is deployed under a different context path.
The homepage works, but internal pages fail
This often points to a servlet mapping issue, incorrect relative links, or a proxy rewrite problem.
Static files load, but Java actions return 404
This can happen when JSPs or servlets are mapped incorrectly, or when the request is reaching Apache but not being forwarded to Tomcat as expected.
The app worked before, then started failing after redeploy
In Tomcat, changing the WAR name, removing the old deployment, or updating the context setup can change the public path. A redeploy is one of the most common reasons for a sudden path mismatch.
Check the deployed context path first
In Tomcat-based hosting, the context path is the part of the URL where the application lives. For example:
https://example.com/means the app is at the root pathhttps://example.com/myapp/means the app is deployed under/myapp
If your application is deployed as myapp.war, Tomcat commonly uses /myapp as the context path. If you rename the WAR file, you may also change the public URL path. That is one of the most frequent reasons for a 404 after upload or redeploy.
Check the following:
- The WAR file name in the deployment directory
- Any custom context configuration in Plesk or Tomcat
- Whether the app is meant to run at the root path or in a subdirectory
- Whether an older deployment is still present and taking precedence
If the app should open at / but is deployed at /myapp, the browser will show a 404 at the root. If the app should be under /myapp but you browse to the root, you will get the same result.
Verify the Tomcat service is running
A public 404 can sometimes hide a service problem. If My App Server or the Tomcat instance is not running, Apache may respond with an error page or forward to nothing useful.
In the hosting control panel, check the service status for your Java application server. Make sure:
- The service is started
- The selected Java version is available and supported
- The app server did not stop because of a failed startup
- The JVM has enough memory for the application to start
If the service starts and then stops immediately, the application may have a deployment error, a missing class, an invalid XML configuration file, or a port conflict. In that case, the path issue is only a symptom. The real cause is that Tomcat never completed startup correctly.
Review Apache and proxy rules
When Apache sits in front of Tomcat, it may proxy requests to the Java app. If the rewrite or proxy rules are wrong, the request path can be altered before it reaches Tomcat.
Typical problems include:
- Rules that strip or add a path segment incorrectly
- Requests to
/being forwarded to a different context - Static files being served by Apache while servlet requests are sent elsewhere
- Conflicting rewrite rules from
.htaccessor panel-generated configuration
If you use Apache with Tomcat in a hosting account, confirm that the public URL and the internal application path match. For example, if Apache rewrites /shop to the Tomcat context /shop, then the application should also be deployed under that same path. If Apache rewrites / to /app, but the app expects root deployment, internal links may break.
Check servlet mappings and JSP paths
Sometimes the 404 is not at the application level but inside the Java app itself. A servlet may be mapped to the wrong URL pattern, or a JSP may be called through a path that no longer exists.
Review:
web.xmlservlet mappings- Annotations such as
@WebServlet - Forward and redirect targets in the code
- Paths used in JSP includes
- Absolute versus relative links
A common mistake is using hardcoded links like /login or /admin without considering the context path. If the application is not deployed at the root, those links bypass the app’s actual location. A safer approach is to build URLs dynamically using the current context path.
Look for hardcoded URLs in the application
Wrong path issues often appear after a move, redeploy, or test-to-production switch because the application was built with fixed URLs. This is especially common in older JSP applications or servlet projects that assume one exact environment.
Search the app for:
- Absolute links starting with
/ - Hardcoded domain names
- Internal redirects to old paths
- JavaScript or CSS references that point to an outdated location
For example, if the application used to run at /myapp but is now deployed at /, a link to /myapp/login will fail. The reverse is also true. If the app is now in a subpath, root-relative links will no longer work correctly.
Confirm the WAR file and deployment name
In many Tomcat hosting setups, the WAR file name defines the public context path. This is one of the most important details to verify.
For example:
ROOT.warusually deploys to the root pathapp.warusually deploys to/appshop-v2.warmay deploy to/shop-v2
If you upload a new WAR with a different name, the URL changes too. If an old deployment directory still exists, Tomcat may also keep files from the previous version, leading to mixed content, old paths, or partial 404 behavior.
To avoid this, make sure you:
- Remove or replace the old deployment cleanly
- Use the intended WAR filename
- Restart the service if the platform requires it
- Check whether the application exploded directory matches the WAR name
Check for missing welcome files or default pages
If the main URL returns 404, but the app is actually deployed, the problem may be that no default page is defined. For example, a request to the context root may need a welcome file such as index.jsp or index.html.
Verify that the application has one of the following if it should load from the root:
- A valid welcome page
- A redirect from the root path to the correct landing page
- A servlet mapped to the application’s start page
If the app works only when you open a deeper path, but not at the base URL, the issue may simply be missing default routing.
Use the hosting control panel to test the service
With a Java hosting solution managed through Plesk and My App Server, the control panel is usually the best place to check service-level problems first. You can often confirm:
- Which Java version is active
- Which Tomcat instance is assigned to the account
- Whether the service is enabled
- Whether logs show startup or deployment errors
- Whether custom configuration was applied
If the control panel shows that the service is running, but the browser still gets a 404, the issue is more likely with the application path or Apache proxying. If the service is not running, fix that first before checking code-level routing.
How to troubleshoot step by step
Use this order to narrow down the cause quickly.
- Open the exact URL that returns the 404 and note the path.
- Check whether the application is deployed at that exact path in Tomcat.
- Confirm that the Java service is running in the control panel.
- Review the deployment name of the WAR file.
- Test the app directly if you have an internal or mapped Tomcat URL.
- Inspect Apache rewrite or proxy configuration for path changes.
- Review logs for startup errors, mapping errors, or deployment failures.
- Test a known servlet or JSP page directly.
- Clear browser cache if redirects or old paths are still being shown.
This approach helps separate a real application error from a hosting path mismatch.
Log files to check
Logs are essential when a Java website returns the wrong path or 404. They tell you whether the request reached Tomcat and whether deployment succeeded.
Look at:
- Tomcat startup logs
- Application deployment logs
- Apache error logs
- Apache access logs
- Java application logs, if the app writes its own output
Common useful messages include:
- Failed to deploy application
- Context path already in use
- Class not found
- JSP compilation error
- Port already in use
- Connection refused to backend
If the logs show that the app never deployed, a 404 is expected. If the logs show successful deployment, then focus on the URL path and proxy rules.
Examples of path mismatch problems
Example 1: WAR renamed during upload
You upload shop.war, and the app works at /shop. Later you rename the file to store.war. Now the browser path changes to /store, but your bookmarks still point to /shop. The result is a 404.
Example 2: App built for root deployment
The application uses root-relative URLs like /assets/style.css. It is deployed under /portal. Static resources then fail because the browser looks for them at the domain root instead of under /portal.
Example 3: Apache rewrite sends requests to the wrong context
Apache forwards /app to Tomcat, but the Tomcat app is actually deployed as /application. The request reaches the server, but the target path does not exist, so Tomcat returns 404.
Example 4: Service stopped after deployment error
The control panel shows the service as configured, but the Java process stopped after a bad classpath change. The browser may still show a generic 404 or proxy error because there is no running backend to answer the request.
How to prevent this issue
You can reduce path and 404 problems by following a few deployment habits:
- Keep the WAR filename consistent with the intended context path.
- Use relative or context-aware links inside the application.
- Confirm Apache rewrite rules after each deployment.
- Do not leave old exploded application folders behind.
- Test the app after every change to the deployment name.
- Keep a note of which Java version and Tomcat version the app expects.
- Check logs after each redeploy, not only when a failure becomes visible.
For hosted Java applications, these small checks are usually enough to avoid most public-facing path errors.
When to contact support
Contact hosting support if you have checked the application path, Tomcat status, and deployment name, but the website still returns the wrong path or 404. Support can usually confirm whether the issue is:
- A control panel configuration problem
- A Tomcat service startup issue
- An Apache proxy or rewrite mismatch
- A deployment problem in My App Server
- A server-side log error that is not visible in the browser
When contacting support, include the exact URL, the deployed WAR name, the current context path, and any recent changes you made. That usually shortens the resolution time significantly.
FAQ
Why does my Java website show 404 after I uploaded a new WAR file?
Most often because the WAR filename changed, which changed the Tomcat context path. The app may now be available at a different URL than before.
Why do links inside my app go to the wrong path?
The app likely uses hardcoded or root-relative URLs that do not match the actual deployment path. Review internal links, redirects, and resource references.
Can Apache cause a Java app to return 404?
Yes. If Apache rewrite or proxy rules point to the wrong Tomcat context, the request may reach the wrong place or no backend at all.
What should I check first in Plesk or My App Server?
Check whether the Java service is running, which WAR is deployed, and what context path the app is using. Those three items solve many path-related 404 issues.
Is a 404 always a code problem?
No. In hosting environments it is often a deployment, context path, proxy, or service issue rather than a bug in the Java code itself.
Why does the homepage work but deeper pages fail?
That usually means the root URL is mapped correctly, but internal servlet routes, redirects, or static resources are pointing to the wrong path.
Summary
When a Java website shows the wrong path or a 404 error, the first thing to verify is the full path chain: browser URL, Apache routing, Tomcat context, and application links. In a hosting setup with My App Server, the issue is often caused by a WAR rename, a context mismatch, a proxy rule, or a startup failure in the Java service. By checking the deployed path, service status, logs, and internal URL references in that order, you can usually identify the cause quickly and restore the correct public-facing URL.