When you host a Java application on Tomcat, two things shape what visitors see in the browser: the public URL and the app path inside Tomcat. In a managed hosting setup with Plesk and My App Server, this relationship matters even more because your app can be deployed as a WAR, run on its own private JVM, and sit behind Apache while still being reachable through a clean public address.
Understanding how Tomcat context paths, virtual hosts, and public URLs work together helps you avoid common issues such as unexpected /app paths, broken links after deployment, redirect loops, and confusion when moving an app from a test URL to a live domain. It also makes it easier to choose the right structure for JSP, servlet, and Java web applications hosted on a shared hosting account with Java support.
How Tomcat maps an application to a public URL
Tomcat serves each web application under a context path. The context path is the part of the URL that identifies the application within the server. For example, if your app is deployed as myapp.war, Tomcat may expose it at /myapp by default.
A public URL is the address your visitors type into the browser, such as https://example.co.uk or https://example.co.uk/shop. In a hosting platform, that public URL may point to Apache first, which then forwards requests to Tomcat or serves static content directly. This is why the browser address may not always match the internal Tomcat deployment name exactly.
The key idea is simple:
- Tomcat context path = internal application path.
- Public URL = the address users access.
- Apache or reverse proxy = may connect the two and rewrite the request flow.
In a control panel environment, you normally configure the domain or subdomain first, then connect it to your Java application through My App Server. The platform manages the service, Java version, and routing so your app can run with a dedicated Tomcat instance or private JVM inside your hosting account.
What is a context root in Tomcat hosting
The context root is the application’s base path within Tomcat. If the context root is /, the app is served from the domain root. If it is /app, then the app lives under that path.
Examples:
https://example.co.uk/→ context root/https://example.co.uk/app→ context root/apphttps://shop.example.co.uk/store→ context root/store
Tomcat often derives the context root from the WAR file name. For instance:
shop.warbecomes/shopcatalog.warbecomes/catalogROOT.warbecomes/
In managed Java hosting, this behaviour is useful because it gives you predictable deployment rules. However, it can also create confusion if your application assumes it is always running at the domain root.
Why public URLs and app paths do not always match
It is common for the visible URL and the Tomcat context path to differ. This happens because the hosting stack may use Apache as the front end and Tomcat as the Java application engine.
For example:
- Public URL:
https://example.co.uk - Tomcat app path:
/myapp - Internal mapping: Apache forwards the request to Tomcat
In this setup, Apache can expose a clean domain while Tomcat still runs the app under its own context. This is a normal pattern in hosting environments that support Java web applications through Plesk and an application server extension.
The mismatch becomes important when your app generates links, builds redirects, or loads assets such as CSS, JavaScript, and images. If the application uses hardcoded paths, it may work at /myapp but fail when published at the root domain.
Typical Tomcat URL and path patterns
Most hosting setups use one of the following patterns:
1. Domain root deployment
The app is deployed as the main site on the domain.
- Public URL:
https://example.co.uk/ - Tomcat context:
/ - Typical file:
ROOT.war
This is the best option when the Java app is the whole website.
2. Subpath deployment
The app is deployed under a specific path.
- Public URL:
https://example.co.uk/app - Tomcat context:
/app - Typical file:
app.war
This works well when Apache serves the main site and Tomcat serves only one application section.
3. Subdomain deployment
The app is mapped to a separate subdomain.
- Public URL:
https://app.example.co.uk/ - Tomcat context:
/or another path - Typical use: separate Java app or administration panel
This is often the cleanest structure when you want to separate a Java application from a main website while keeping the deployment simple.
How this works in My App Server and Plesk
In ITA’s My App Server environment, Java hosting is managed through a Plesk extension designed to make Tomcat and private JVM usage practical on shared hosting. You can install a ready-made Java/Tomcat version with a button, or upload and configure another version manually when needed.
From a path and URL perspective, the platform typically helps you with:
- creating the Java service for the hosting account,
- choosing the Java version,
- starting and stopping the service,
- deploying WAR-based applications,
- connecting the app to the selected domain or subdomain.
This is especially useful for JSP hosting, servlet hosting, and small to medium Java web applications that need their own runtime without the complexity of an enterprise application server setup.
When configured correctly, Apache can present the public domain while Tomcat handles the Java part in the background. This gives you a stable path structure without requiring direct server-level administration.
How to choose the right path structure
Before deploying, decide where your app should live in the browser. That choice affects your links, redirects, and relative resource paths.
Use the domain root when the app is the website
If the Java application is the main site, deploy it at the root context. This keeps URLs shorter and reduces the chance of broken links.
- Best for: primary websites, application front ends, portals
- Use:
ROOT.waror root context mapping - Benefit: simple public URL structure
Use a subpath when the app is part of a larger site
If the Java app is only one section of the website, a subpath may be better.
- Best for: member areas, admin tools, booking sections
- Use: context such as
/appor/portal - Benefit: keeps Apache site and Java app logically separate
Use a subdomain when separation is helpful
A subdomain can make maintenance easier, especially if the app has its own login area or should be isolated from the main content structure.
- Best for: app.example.co.uk, test.example.co.uk, dev.example.co.uk
- Use: domain or subdomain mapping to Tomcat
- Benefit: clearer routing and cleaner deployment boundaries
Common issues caused by incorrect app paths
Many Tomcat hosting problems are not caused by Tomcat itself, but by path mismatch. Here are the most common ones.
Broken links after deployment
If your app generates links like /css/style.css or /login without considering the context root, the browser may look for those files at the domain root even when the app is deployed under /myapp.
How to avoid it:
- use relative URLs when appropriate,
- build links using the application context,
- avoid hardcoding root-based paths unless the app truly runs at
/.
Wrong redirects
Login pages and post-submit redirects can break if the application redirects to a path that does not match the public URL structure.
How to avoid it:
- check your redirect targets after deployment,
- confirm whether the app is behind Apache or mapped directly,
- test both HTTP and HTTPS URLs if your hosting plan uses SSL.
Static assets not loading
If CSS, JavaScript, or images fail to load, the app may be referencing paths that do not include the context root.
How to avoid it:
- verify asset URLs in the browser developer tools,
- make sure the build uses the correct base path,
- recheck Apache and Tomcat path mappings.
App works on test URL but not on the live domain
This often happens when the test deployment uses one context root and the live site uses another. The code may assume a different base path than the one actually configured.
How to avoid it:
- document the final public URL before release,
- use environment-specific configuration where needed,
- retest the application after the path mapping changes.
Practical steps to align Tomcat paths with public URLs
Use the following workflow when deploying a WAR or updating a Java app in a managed hosting control panel.
Step 1: Decide the final public address
Choose whether the app should run on the domain root, a subpath, or a subdomain. This should be decided before deployment, not after.
Step 2: Check the WAR file name or context configuration
Tomcat usually uses the WAR file name as the context root. If you want the app at the domain root, rename the package to ROOT.war if your deployment process supports it.
Step 3: Confirm the Apache-to-Tomcat routing
In hosting setups that combine Apache and Tomcat, make sure the public URL points to the right application service. If Apache is the public front end, it should forward only the expected requests to Tomcat.
Step 4: Adjust app-generated URLs
Review any places where the application creates links, form actions, or redirects. Ensure they respect the base path used in production.
Step 5: Test static and dynamic content
Open the public URL in a browser and check:
- the home page,
- navigation links,
- login and form submission,
- CSS and JavaScript loading,
- image paths and downloads.
Step 6: Recheck after each release
If you upload a new build or switch app versions, confirm that the public path still matches the deployed context. Small changes in packaging can alter the URL structure.
Best practices for JSP and servlet hosting
JSP and servlet applications are especially sensitive to path handling because they often generate internal links dynamically. A few practical rules help keep deployments stable.
- Use context-aware path building instead of hardcoded absolute paths.
- Keep resource references consistent across development and production.
- Use a separate configuration for the public base URL when needed.
- Test sessions, form actions, and file uploads after every deploy.
- Prefer simple context structures that are easy to maintain in Plesk.
If the app is small or medium-sized, running it on a private JVM or dedicated Tomcat instance within the hosting account can give you enough isolation and control without needing a complex enterprise server stack.
How Apache affects the visible URL
When Apache is in front of Tomcat, it may serve the main site, handle SSL, or route requests to the Java application. In this arrangement, Apache can hide the internal Tomcat path from visitors.
This is useful because:
- you can keep clean public URLs,
- you can separate static content from Java content,
- you can manage the site through the hosting control panel.
However, Apache can also introduce rewrites or proxy rules that change how paths behave. If your app expects /app but Apache forwards requests differently, the browser may see one URL while Tomcat receives another. That is normal, but your application must be built with that behavior in mind.
When to use a root context and when not to
Root deployment is convenient, but it is not always the best choice.
Use the root context if:
- the Java app is the main website,
- you want the shortest public URLs,
- there is no other website content on the same domain.
Do not use the root context if:
- the domain already hosts a traditional site in Apache,
- you want multiple apps under one account,
- you need to keep a test area separate from the live app.
In many hosting cases, a subdomain is the easiest way to keep the structure clear while still using Tomcat efficiently.
FAQ
What is the difference between a public URL and a Tomcat context path?
The public URL is the address users visit in the browser. The Tomcat context path is the internal path used by the application server to identify the app. They may be the same, but they do not have to be.
Why does my app appear under /myapp instead of the domain root?
Tomcat commonly uses the WAR file name as the context root. If your WAR is named myapp.war, it will usually deploy to /myapp. To serve it at the root, the deployment must be configured accordingly.
Can Apache hide the Tomcat path from visitors?
Yes. Apache can act as the public front end and forward requests to Tomcat. This lets you show a clean domain or subdomain while Tomcat runs the application behind the scenes.
Why do my CSS and JavaScript files break after deployment?
This usually happens because the app uses hardcoded paths that do not match the deployed context. Recheck how static files are referenced and make sure the code uses the correct base path.
Can I run a Java application on a shared hosting account?
Yes, if the hosting platform includes Java support such as My App Server. In that case, you can run a private Tomcat or JVM instance within the hosting account for suitable small and medium applications.
Do I need a full enterprise application server for this?
Not for most JSP, servlet, or standard Tomcat-based applications. A managed Tomcat setup is often enough when you only need practical deployment, version control, and service management through Plesk.
What should I check first if the public URL returns an error?
First check whether the domain points to the correct application, then verify the Tomcat service status, the deployed context path, and any Apache rewrite or proxy settings. Also confirm that the app was uploaded and started successfully.
Conclusion
Public URLs and Tomcat app paths work together, but they serve different purposes. The browser sees the public URL, while Tomcat uses the context root to locate the application. In a managed hosting environment with Plesk, Apache, and My App Server, the hosting platform can bridge those two layers, but the application still needs to be configured with the right path structure.
For the cleanest result, decide early whether the app should run at the domain root, under a subpath, or on a subdomain. Then deploy the WAR, test resource paths, and confirm that redirects and links match the final public URL. This approach keeps Java hosting, Tomcat hosting, JSP hosting, and servlet hosting easier to manage and reduces deployment problems during updates.