When you host a Java application on Tomcat, the public URL that visitors use is not the same thing as the internal app path on the server. Tomcat combines the application’s context root, the deployed folder or WAR name, and any proxy or web server rules to decide what the final address looks like in a browser. Understanding that relationship is important when you deploy a WAR file, move an app, change a context root, or want a clean public URL such as /app instead of a longer path.
In a managed hosting environment with Plesk and My App Server, this becomes even more practical. You can run your own Tomcat instance, choose a Java version, control the service, and deploy JSP, servlet, or WAR-based applications without needing a full enterprise Java stack. At the same time, you still need to make sure that the app path inside Tomcat matches the public URL you want users to see.
How Tomcat maps an application to a URL
Tomcat uses a concept called a context. The context tells Tomcat where the application lives and which URL path should trigger it. In simple terms:
- App path is the internal name or location of the application inside Tomcat.
- Context root is the URL segment that activates the app.
- Public URL is the address visitors enter in the browser.
For example, if your application is deployed as myapp.war, Tomcat may expose it at /myapp. If it is deployed as the root application, it may be available directly at /.
In a hosted environment, the final URL can also be influenced by Apache, reverse proxy rules, or control panel settings. That means the browser address may look simple, while Tomcat still uses a more specific internal context path behind the scenes.
Public URL, context root and deployment name: what is the difference?
These three terms are closely related but not identical.
Public URL
The public URL is the address users open in a browser. For example:
- https://example.com/
- https://example.com/shop
- https://app.example.com/api
This is what users and external systems see.
Context root
The context root is the path Tomcat uses to route requests to your application. If the context root is /shop, then requests to /shop are sent to that app.
Deployment name
The deployment name is often the WAR file name or the folder name inside Tomcat. For example:
- shop.war often becomes /shop
- ROOT.war usually becomes the site root /
In many cases, deployment name and context root are linked, but in a managed hosting panel they can be configured independently.
How public URLs and app paths work together on Tomcat hosting
Tomcat receives a request and checks the path in the URL. It compares that path with the configured context root and forwards the request to the correct application. If there is a match, your app handles the request. If there is no match, the request may go to another app, a default root app, or return a 404 error.
Here is the basic flow:
- A visitor opens a public URL in the browser.
- Apache, a proxy, or Tomcat receives the request.
- The server checks the path part of the URL.
- Tomcat matches it against the deployed context.
- The request is routed to the correct app inside the JVM.
This is why a working Tomcat deployment depends on both the correct app path and the correct public URL configuration.
Common deployment patterns
1. Application at the root of the domain
If you want the app to open at https://example.com/, deploy it as the root context. In Tomcat this is commonly done with ROOT as the application name or context.
Typical use cases:
- Main website
- Single-app domain
- Landing page or frontend application
Useful when you do not want visitors to type a subpath such as /app or /tomcat.
2. Application under a subpath
If you want the app to open at https://example.com/shop, the context root should be /shop. In this case the app is not the site root. It lives under a dedicated path.
Typical use cases:
- Multiple applications on one domain
- Admin panels
- Legacy JSP or servlet apps
3. Application on a subdomain
Sometimes Tomcat is connected to a subdomain such as app.example.com. The app may then run at the root of that hostname, for example:
- https://app.example.com/
This is a clean setup for Java hosting because the application can remain at the root while still being separated from the main website.
How My App Server helps with Tomcat path management
In the ITA managed hosting environment, My App Server provides a practical way to run your own Java/Tomcat service inside a hosting account. You can install supported Java and Tomcat versions, manage the service from Plesk, and deploy your application without needing to maintain a separate server stack.
For path management, this means you can:
- Install a Tomcat instance and control its service
- Deploy WAR files and define how they are exposed
- Use a private JVM for your app
- Adjust the public URL structure more easily than on a standard file-only hosting plan
This is especially useful for Java hosting, Tomcat hosting, JSP hosting, servlet hosting, and smaller private JVM deployments where control panel visibility is important.
What happens when the app path does not match the public URL
Problems often appear when the application is deployed correctly but the browser opens the wrong URL, or when the URL is correct but Tomcat cannot find the app.
Common symptoms include:
- 404 Not Found when opening the expected URL
- The homepage loads, but links or assets return errors
- The app opens under an unexpected path
- Redirects send users to the wrong location
- Login or API endpoints fail because the base path is wrong
Usually the cause is one of the following:
- WAR file name does not match the desired context root
- Context definition in Tomcat is incorrect
- Apache proxy or rewrite rule points to a different path
- The application generates absolute URLs that do not match the deployed path
- The app was built for a different base path and has not been updated
How to check the current context path
If you are using Tomcat hosting, the first step is to verify where the application is actually deployed.
Check the deployment name
Look at the WAR or folder name. A file called orders.war often becomes /orders. A file called ROOT.war usually becomes the root application.
Check Tomcat configuration
Review any context definition files or deployment settings that define the path. In some managed setups, the control panel or extension handles this automatically.
Check the browser URL
Compare the browser address with the expected public path. If the app is supposed to be at /app but opens at /myapp, the context root likely needs adjustment.
Check Apache or proxy rules
If Apache sits in front of Tomcat, the public URL may be rewritten before the request reaches the Java app. A path that looks correct in the browser may still be mapped differently behind the scenes.
How to set a clean public URL for a Tomcat app
If you want a neat and predictable public URL, plan the path before deployment.
Step 1: Decide the final URL
Choose the public path you want users to see. Common examples:
- /
- /app
- /portal
- /api
Step 2: Match the deployment name or context
Deploy the WAR with a matching name where possible. If your target is /portal, use a deployment name that reflects that path, or define the context explicitly in Tomcat.
Step 3: Make the app aware of its base path
Many Java applications generate links, redirects, and asset paths based on a context base URL. If this is hardcoded, move it to a configurable setting so the app works in both local testing and hosted deployment.
Step 4: Verify redirects and static resources
After deployment, open pages that include CSS, JavaScript, images, login redirects, and API calls. These often reveal path issues quickly.
Step 5: Test from the exact public URL
Do not test only through localhost or a temporary internal URL. Always test through the final public address, because Apache and proxy routing can change the path behaviour.
Best practices for WAR, JSP and servlet apps
Tomcat hosting works best when the app is built with deployment in mind.
- Use relative paths carefully. Hardcoded absolute paths can break when the context changes.
- Keep the context root stable. Changing it later may affect bookmarks, API clients, and redirects.
- Prefer one app per domain or subdomain if you want the cleanest URL structure.
- Keep the ROOT app empty or purposeful. A random default root application can confuse visitors.
- Test with the same Java version that will run in production hosting.
- Review external links and callback URLs after every deploy.
For JSP and servlet applications, the context path is often part of page rendering, navigation, and form submission. That makes path consistency especially important.
How Apache and Tomcat interact in managed hosting
In many hosting environments, Apache handles the public web entry point while Tomcat runs the Java application behind it. Apache may serve static files directly and forward specific paths to Tomcat. This can improve flexibility, but it also means the visible URL can be shaped by proxy rules.
Typical patterns include:
- Apache serves / and proxies /app to Tomcat
- Apache redirects a clean domain to a Tomcat context
- Tomcat serves the whole site directly on a dedicated host name
If the public URL does not behave as expected, check whether Apache is rewriting, forwarding, or redirecting the request before it reaches Tomcat.
Examples of path behaviour
Example 1: WAR file name controls the URL
If you upload shop.war, Tomcat may expose it as /shop. The app then opens at:
- https://example.com/shop
If you rename the WAR to ROOT.war, the same app may open at:
- https://example.com/
Example 2: App generates the wrong links
An app deployed at /portal still generates links like /login instead of /portal/login. This usually means the application is not using the correct base context when building URLs.
Example 3: Reverse proxy hides the internal Tomcat path
Tomcat may run the app under /myapp, while Apache exposes it as / on a separate domain or subdomain. The public URL looks simple, but the internal app path remains different.
Troubleshooting checklist
If the public URL and app path do not behave together correctly, use this checklist:
- Confirm the WAR or app folder name
- Check the Tomcat context root
- Verify the Plesk or My App Server deployment settings
- Inspect Apache proxy or rewrite rules
- Look for hardcoded links in the application
- Clear browser cache if old redirects are still stored
- Restart the service after changing deployment settings
In managed Java hosting, restarting the Tomcat service is often necessary after context or application changes so the new path is picked up correctly.
When to use a root context and when to use a subpath
A root context is best when the Tomcat app is the main website for that domain or subdomain. It gives the cleanest user experience.
A subpath is better when:
- You want to host more than one app
- The Java app is only one part of the website
- You need a separate admin or test interface
- You want to avoid conflicts with an existing site on the same domain
For many small and medium Java deployments, a clean subdomain or root domain setup is easier to maintain than multiple nested paths.
Frequently asked questions
Is the app path the same as the public URL?
Not always. The app path is the internal context used by Tomcat, while the public URL is the browser address. They can match, but they can also differ if Apache, a proxy, or control panel settings are involved.
Why does my WAR file open under a different path?
Tomcat often uses the WAR file name as the context root. If the file is named differently from the path you expect, the app may open under that name instead. In some setups, a context definition overrides the WAR name.
Can I change the Tomcat context root after deployment?
Yes, but you should do it carefully. Changing the context root can break links, bookmarks, API clients, and redirects if the app is not updated to use the new base path.
Why do static files work but API calls fail?
Static files may be loaded with relative paths, while API calls or redirects may use hardcoded absolute paths. This often happens when the application was built for a different context root.
Does My App Server support controlling the Tomcat service?
Yes. In the hosting environment, the service can be managed through Plesk and the My App Server extension, which is useful when you need to restart or update the Java application after deployment changes.
Can I run a private JVM with its own app path?
Yes. That is one of the practical use cases of My App Server. You can run a private JVM and Tomcat instance inside a managed hosting account and control how the app is exposed.
Is this suitable for enterprise clustering or complex HA setups?
This setup is designed for practical Java hosting and Tomcat hosting on managed infrastructure, not for heavy enterprise clustering or complex high-availability architectures.
Conclusion
Public URLs and app paths work together through Tomcat’s context mapping. The browser sees the public address, but Tomcat routes the request based on the internal application context. In managed hosting, especially with Plesk and My App Server, understanding that relationship helps you deploy cleaner URLs, avoid 404 errors, and keep JSP, servlet, and WAR applications working as expected.
Before deploying, decide whether your app should live at the root of the domain or under a subpath. Then make sure the Tomcat context, WAR name, and any Apache or proxy rules all point to the same result. That simple alignment prevents most path-related issues in Java hosting.