When you run a Java web application on a managed hosting platform, the public URL that visitors use and the internal app path that Tomcat or your JVM uses are related, but they are not always the same thing. Understanding this difference helps you avoid broken links, wrong redirects, duplicate content, and deployment issues after an update.
In a typical Java hosting setup with My App Server in Plesk, your application can be deployed as a WAR, JSP, or servlet-based app inside a private Tomcat instance or private JVM. The app may be published under a domain, subdomain, or a path such as /app, while the servlet context, static resources, and reverse proxy rules may follow different internal rules. This is why public URLs and app paths need to be planned together.
How public URLs and app paths relate in Java hosting
A public URL is the address a user types in a browser, for example https://example.com/shop. An app path is the path your Java application uses internally, often called the context root in Tomcat. In many Java hosting environments, the context root is what determines the first part of the path after the domain.
For example:
- Public URL:
https://example.com/shop - Tomcat context root:
/shop - Application route:
/products - Final browser URL:
https://example.com/shop/products
This means the browser sees one URL, while your app still uses its own routing and resource paths behind the scenes. If these layers are not aligned, links can break even when the app is running correctly.
Context root, document root and reverse proxy: the basic difference
In hosting control panels such as Plesk, you may deal with three different concepts:
1. Context root
This is the Java application path inside Tomcat. It defines where the app lives in the servlet container. If the context root is /, the app is at the domain root. If it is /app, the app is under that subpath.
2. Document root
This is the web directory served by the web server, often Apache. For static sites, the document root is where files are published. For Java hosting, Apache often acts as a front layer and forwards requests to Tomcat or your private JVM through the configured service.
3. Reverse proxy path or public path
This is the path shown in the browser and handled by Apache, Plesk, or a proxy rule. It may match the Tomcat context root, but it does not have to. A proxy can expose one path publicly while forwarding to another internal target.
In practice, the safest setup is to keep the public path and the application context root consistent whenever possible. That reduces confusion in redirects, cookies, session handling, and generated links.
Why path alignment matters for Tomcat hosting
Java web apps often generate URLs dynamically. If your app thinks it lives at the root domain but it is actually served under a subpath, you can see issues such as:
- broken CSS, JavaScript, or image links
- 404 errors after login or form submission
- redirect loops
- incorrect canonical URLs for SEO
- session cookies scoped to the wrong path
- links that work in development but fail after deployment
This is especially important for JSP hosting and servlet hosting, where many links are created by templates or server-side code. It is also important when using My App Server inside a shared hosting account, because the application is isolated inside its own service, but it still needs to fit cleanly into the public site structure.
Common deployment patterns in My App Server
With ITA’s Java hosting via the My App Server Plesk extension, you can usually deploy your app in one of these ways:
Application at the domain root
Your app is published as https://example.com/. This is the simplest option when the Java application is the main site.
Typical use cases:
- single-app websites
- main web portal
- small business sites built with JSP or servlets
Application under a subpath
Your app is published as https://example.com/app or https://example.com/shop. This is useful if you want to keep the main site separate from the Java app or host multiple apps under one domain.
Typical use cases:
- admin panels
- internal tools
- legacy Java applications
- test or staging releases
Application on a subdomain
Your app is published as https://app.example.com/. This is often easier to manage than a subpath, because static assets, session cookies, and redirect logic are usually simpler.
Typical use cases:
- separate app frontends
- REST-backed user interface layers
- multiple services under one hosting account
How Tomcat context paths work
In Apache Tomcat, the context path is usually derived from the WAR file name or from a deployed context configuration. For example:
ROOT.waris often deployed at the domain rootshop.waris often deployed at/shop- a custom context definition can map the app elsewhere, depending on the hosting setup
In a managed hosting environment, you normally do not need to edit low-level server files directly. Instead, you use the control panel, service settings, or deployment process provided by the platform. With My App Server, this is designed to be more practical for shared hosting users who want a private JVM or Tomcat instance without managing the full server manually.
How public URL generation should be handled inside your app
Your Java app should not hardcode full URLs unless it is absolutely necessary. Hardcoded URLs often fail when the context root changes or when the app is moved from a subpath to a subdomain.
Better approaches include:
- using relative paths for internal links
- building links from the request context path
- using framework helpers where available
- configuring base URLs through environment or app settings
For example, if your app is deployed under /shop, a link to a product page should usually respect the current context path instead of assuming the app is at the domain root.
This matters most for:
- login and logout redirects
- form post actions
- static resource URLs
- API endpoints called from the browser
- canonical and Open Graph URLs for SEO
Static resources and relative paths
One of the most common problems in Java hosting is that CSS and JavaScript files work in the development environment but fail after deployment. The usual reason is that the app path changed.
For example, a stylesheet referenced as /css/main.css assumes the app is at the root domain. If the app is deployed under /app, that link may point to the wrong location. In that case, the browser will request:
https://example.com/css/main.css
instead of:
https://example.com/app/css/main.css
To avoid this, use path-aware references in your application or choose a deployment structure that matches the app’s assumptions.
SEO implications of public URLs and context roots
Public URL design affects search engine visibility. If the same content is available at multiple paths, search engines may treat those as separate pages unless you handle the URLs properly.
Best practices include:
- choose one canonical public path for each page
- avoid exposing duplicate content under multiple URLs
- make redirects consistent when moving an app
- ensure sitemap entries match the final public URL
- update canonical tags after changing the context root
If your app moves from /app to the domain root, or from one subdomain to another, review all SEO-sensitive URLs. This is important for hosted Java applications that serve content pages, product listings, or documentation pages.
How to plan app paths before deployment
Before uploading a build to My App Server, decide how the app should be exposed publicly. That saves time later and reduces the risk of path-related bugs.
Step 1: Choose the public location
Decide whether the app should be at:
- the root domain
- a subpath like
/app - a subdomain like
app.example.com
Step 2: Check how the app builds URLs
Review templates, controllers, filters, and frontend code for hardcoded paths. Pay attention to:
- login redirects
- form actions
- resource URLs
- file upload and download links
- API base paths
Step 3: Match the Tomcat context root
If possible, deploy the WAR with a context root that matches the intended public path. This keeps the application and the browser URL aligned.
Step 4: Test after deployment
Open the site in a browser and verify:
- homepage loads correctly
- all static assets are found
- forms submit to the right location
- login and logout redirects work
- URLs in the page source are correct
Practical examples
Example 1: Java app at the root
If the application is deployed as the main site, the Tomcat context root may be /. In this case, a page called /dashboard appears as:
https://example.com/dashboard
This is the cleanest option when the Java app is the only public website for the domain.
Example 2: app under /portal
If the application is deployed under /portal, then the same page becomes:
https://example.com/portal/dashboard
All internal links and static resources should respect that base path.
Example 3: separate app on a subdomain
If the app is published as app.example.com, then the context root is often / again. That means your app can keep simpler paths while still being isolated from the main site.
Common mistakes to avoid
- hardcoding
http://instead of using the correct scheme - assuming the app will always stay at the domain root
- mixing relative and absolute URLs without a plan
- moving a WAR to a new context root without updating links
- forgetting to change canonical URLs after a path migration
- using static resource paths that ignore the app context
These issues are common in Java hosting, especially for JSP and servlet applications that were originally developed for a local Tomcat instance and later deployed to a managed platform.
What to check in Plesk and My App Server
In a hosting control panel, you should usually review the following before going live:
- which Java version the app runs on
- whether Tomcat or a private JVM is enabled
- the deployed app name and context path
- service control status
- limits that may affect runtime behavior
- Apache or proxy settings if the app is exposed through a front-end web server
My App Server is designed to make these tasks manageable from Plesk, so you can upload, install, and control a Java application without treating the server as a full enterprise application platform. That is useful for small and medium Java projects that need a private runtime and predictable public URL behavior.
Troubleshooting path and URL issues
My CSS and JS files return 404
This usually means the app is deployed under a different path than your code expects. Check whether the application is using root-based URLs while the context root is actually a subpath.
Login redirects go to the wrong place
Review the app’s redirect logic and base URL configuration. A redirect that works locally may fail after deployment if the public path is different.
The browser shows duplicate URLs for the same page
This often happens when both the root domain and a subpath expose similar content. Add redirects or canonical tags so search engines and users see one preferred URL.
Session ends after moving between pages
Check cookie path settings and verify that all requests use the same public base path. If the app is moved from root to subpath, session handling may need adjustment.
The app works on Tomcat but not through Apache
This can happen when Apache or the proxy layer rewrites paths differently from Tomcat. Review the front-end mapping and make sure the public URL matches the path the app expects.
Best practices for Java hosting path design
- keep the public path simple and stable
- prefer one canonical URL per page
- avoid hardcoded absolute paths in templates
- test the app after every deployment
- document the chosen context root for your team
- use the hosting control panel to keep deployment settings consistent
These practices are especially useful when working with managed Java hosting, Tomcat hosting, or private JVM hosting in a shared hosting account. They reduce deployment risk and make release updates easier to manage.
FAQ
Is the public URL the same as the Tomcat context path?
Not always. They can be the same, but a public URL may also be created by Apache or a proxy rule that forwards traffic to a different internal path.
Should I deploy Java apps at the root domain or under a subpath?
Both are valid. Root deployment is simpler for a single main app. Subpath deployment is useful when you need to separate multiple apps or keep a main website and Java app on the same domain.
Why do relative links sometimes break after deployment?
Because the app path in production may differ from your local setup. If the app is no longer at the root, links that assume / can point to the wrong location.
Can I change the context root after deployment?
Yes, but you should also update redirects, resource URLs, canonical tags, and any external links that point to the old path.
What is the safest approach for SEO?
Use one preferred public URL structure, avoid duplicate content, and make sure internal links, sitemaps, and canonical tags match the actual deployed path.
Does My App Server support practical Java hosting for small and medium apps?
Yes. The platform is intended for practical Java hosting use cases such as Tomcat, JSP, servlet, and private JVM deployments inside a managed hosting account, with control through Plesk.
Conclusion
Public URLs and app paths must be planned together in Java hosting. If your Tomcat context root, Apache mapping, and application-generated links all agree, your app is much easier to deploy, maintain, and optimize for search engines. In a managed environment like My App Server, this approach gives you the benefit of a private Java runtime with predictable public behavior, without the complexity of enterprise-scale infrastructure.
Before each release, check the deployed path, review URL generation in the app, and confirm that static resources and redirects still work. That simple habit prevents many of the most common problems in Java hosting.