On Java hosting, the public URL and the app path do not always mean the same thing. In a Plesk-based setup with My App Server, your application may run inside its own Apache Tomcat instance or private JVM, while visitors access it through a clean public address such as https://example.com, https://www.example.com/app, or another configured path. Understanding how these pieces fit together helps you avoid 404 errors, broken links, mixed content, and deployment issues after an update.
In practice, the public URL is the address users type in the browser, while the app path is the internal or context-based location where your Java application is published. On Java hosting, especially with Tomcat and WAR deployments, the app path is often called the context root. In managed hosting, this mapping can be handled by Tomcat itself, by Apache, or by the hosting control panel configuration, depending on how the service is set up.
How public URLs and app paths differ
A public URL is the visible entry point for your website or application. An app path is the part of the URL that points to a specific application or context. For example, if your main site is at https://www.example.co.uk and your Java app is published at /shop, the full public URL becomes https://www.example.co.uk/shop.
With Java hosting, the application may also be published at the root path, meaning the app loads directly from /. In that case, the public URL and the app URL look the same to the visitor, even though the application may still be running in its own Tomcat context behind the scenes.
The key idea is simple:
- Public URL = what the visitor sees and uses.
- App path / context root = where the Java app is mounted.
- Apache or reverse proxy rules = how requests are forwarded to Tomcat or the JVM.
- Plesk / My App Server settings = how the hosting platform manages the deployment and routing.
Why this matters on Java hosting with Tomcat
Java applications often rely on context paths to route traffic correctly. A WAR file named myapp.war is commonly deployed as /myapp, unless the host or control panel assigns another path. If your application assumes it is running at the root path but it is actually deployed under a subpath, links to static files, APIs, login pages, and redirects can fail.
This is especially important on managed Java hosting where the platform may provide:
- a preinstalled Tomcat version,
- an independently managed JVM,
- custom service control inside Plesk,
- Apache in front of Tomcat,
- multiple deployment options for WAR, JSP, or servlet-based apps.
When the public URL and context root are aligned correctly, users get a stable and predictable address. When they are not, you may see:
- broken internal links,
- redirect loops,
- missing CSS or JavaScript files,
- incorrect redirect destinations after login,
- 404 errors for API endpoints or JSP pages.
How context roots work in Tomcat
In Apache Tomcat, each web application usually has a context root. This is the path segment after the domain name. For example, if a servlet application is deployed at /billing, then a request to https://example.com/billing reaches that application.
Depending on the setup, the context root may be defined by:
- the WAR file name,
- a context XML file,
- deployment rules in the hosting panel,
- a reverse proxy mapping from Apache to Tomcat.
On hosted Java environments, the control panel can simplify this by exposing a service such as My App Server. That means you can install a Java version, start or stop the service, and deploy your app without manually building a full application server stack.
Common context root examples:
- / for the site root
- /app for a single application under the main domain
- /api for a backend API
- /admin for an administrative interface
How Apache and Tomcat share the public address
In many hosting environments, Apache handles the public-facing web traffic and forwards selected requests to Tomcat. This is useful when you want static files, PHP pages, or redirects to be handled by Apache, while Java requests are delivered to your Tomcat-based application.
The public URL remains the same for the visitor, but the internal route may be different. For example:
- Public request: https://example.com/shop
- Apache receives the request
- Apache forwards it to Tomcat
- Tomcat serves the app deployed at context /shop
This separation is useful, but it also means you need to be careful with path handling. If the app generates links as if it lives at /, the browser may try to load assets from the wrong location. If Apache rewrites paths differently from what Tomcat expects, you can get inconsistent behaviour.
Typical deployment patterns in My App Server
With ITA’s My App Server approach, Java hosting is designed for practical app deployment on shared hosting accounts. You can install and manage a private Tomcat or JVM service in Plesk, choose from supported Java versions, and deploy your application in a controlled way.
1. Application at the domain root
This is common for a single Java site. The app is published at /, so the main URL is the application URL. This works well when the Java application is the primary website.
Example:
- Domain: https://www.example.co.uk
- App path: /
- Visible site URL: https://www.example.co.uk
2. Application under a subpath
Useful when Java is only part of the site, or when you want to run more than one app on the same hosting account.
Example:
- Domain: https://www.example.co.uk
- App path: /portal
- Public URL: https://www.example.co.uk/portal
3. Separate app on a subdomain
Some installations use a subdomain such as app.example.co.uk. The Java application still has a context path, but from the visitor’s point of view the public URL is a separate host name.
Example:
- Subdomain: https://app.example.co.uk
- App path: / or /app
- Public URL: https://app.example.co.uk or https://app.example.co.uk/app
How to check what path your Java app is using
If your application is not loading as expected, the first step is to confirm the actual context path. In a managed hosting environment, this is often visible in the deployment or service settings.
- Open the hosting control panel.
- Go to the Java service or My App Server section.
- Check which Tomcat or JVM instance is assigned to the domain.
- Review the deployed application name and context.
- Confirm whether the app is mounted at / or a subpath such as /app.
If the panel allows service control, you may also be able to restart the app after changing the deployment or context settings. This is often necessary after updating a WAR file or modifying context-related configuration.
How to make links work correctly inside the app
Many path-related problems happen because an application uses hard-coded links. If the app is deployed under a subpath, absolute links that start at / may point to the wrong place.
Use the correct base path
Java web apps should generate links using the application’s actual base path when possible. This is especially important for JSP pages, servlet redirects, form actions, and static resource URLs.
For example, instead of linking directly to /images/logo.png, the app should use the current context path so that the image loads whether the app is mounted at / or /portal.
Avoid assumptions about the root directory
If you develop locally with a root context but deploy under a subpath in hosting, paths can break after release. Always test:
- main navigation links,
- form submissions,
- login and logout redirects,
- API endpoints,
- CSS, JS, and image paths.
Check redirect targets
If a login page sends the user back to the home page, make sure the redirect target includes the correct app path. A redirect to /home may fail if the app lives at /portal. In that case the correct target may be /portal/home or a context-aware equivalent.
Public URL issues that often appear after deployment
When you upload a new build to Java hosting, the app path may stay the same, but the public behaviour can still change if configuration or context mapping changes. The most common issues include:
- 404 on refresh — often caused by routing or rewrite rules not matching the app path.
- Assets missing — CSS, JS, or images are requested from the wrong base URL.
- Wrong redirect after login — the app generates a redirect without the context prefix.
- App opens at the wrong URL — the domain points to a different document root or proxy target.
- Mixed routing — Apache serves some requests while Tomcat serves others, but the application expects a single path model.
In a Plesk-managed environment, these problems are usually solved by checking the service assignment, the deployment path, and any Apache configuration that forwards requests to the Java service.
Practical steps to align public URL and app path
Use the following checklist when you deploy or update a Java app on hosting with My App Server.
- Confirm the domain or subdomain that should serve the application.
- Check the app context root in the Java service or deployment settings.
- Verify the WAR name if the hosting setup uses file-name-based deployment.
- Review Apache or proxy rules if the domain is fronted by Apache.
- Test the app with the browser using the exact public URL.
- Open a few internal pages to confirm navigation and resources load correctly.
- Restart the Java service after changes if the control panel requires it.
If the app should run at the domain root
Make sure the Java deployment is mapped to / and that no conflicting document root or proxy rule is taking precedence. Also verify that the site’s main public URL points to the intended service.
If the app should run under a subpath
Confirm that the Tomcat context matches the desired path and that the application is built to work with that base path. If necessary, adjust the app so all links and redirects are context-aware.
How Plesk and My App Server help with path management
One advantage of managed Java hosting is that you do not need to manually maintain every layer of the runtime. With My App Server in Plesk, you can manage Java hosting through a control panel interface, select a supported Java version, start or stop the service, and deploy your application in a more predictable way than on a fully manual setup.
This is useful for:
- small and medium Java web applications,
- Tomcat hosting for WAR-based sites,
- JSP hosting,
- servlet hosting,
- private JVM hosting inside a shared account.
Because the application is deployed within a managed service, public URL mapping can be easier to maintain, especially when you need to re-release the app or change versions without rebuilding the hosting environment from scratch.
Best practices for stable URLs on Java hosting
- Keep the public URL structure simple.
- Use the same context path in staging and production where possible.
- Do not hard-code absolute paths unless they are truly global.
- Test the app after every release with the real public URL.
- Restart or refresh the Java service when required by the panel.
- Confirm that Apache, Tomcat, and the deployed app agree on the same path mapping.
If you manage multiple applications in one hosting account, document each app path clearly. This reduces confusion when you update builds, create redirects, or move one app from /app1 to /app2.
FAQ
What is the difference between a public URL and a context root?
The public URL is the browser address used by visitors. The context root is the path where the Java application is deployed inside Tomcat or the hosting service.
Can my Java app run at the domain root?
Yes. If the app is deployed at /, visitors can access it directly from the domain root. This is common for primary websites and single-app deployments.
Why do my CSS and JavaScript files stop loading after deployment?
This usually happens when the app is deployed under a different path than it expects. The resource URLs may still point to / instead of the real application context.
Does Apache change my Java app path?
Apache can affect how requests reach Tomcat, especially if it is acting as a front-end or reverse proxy. The visible URL stays the same, but the forwarding rules may influence which app path is reached.
How do I know whether my app is on Tomcat or a private JVM?
Check the Java hosting or My App Server section in the control panel. There you can usually see the assigned service, Java version, and deployment details.
Can I host more than one Java app on the same account?
Yes, if the hosting plan and service configuration allow it. Each app should have a clear public URL and context path so that routing stays predictable.
Conclusion
On Java hosting, the public URL and app path work together to decide how users reach your application. In a Plesk and My App Server environment, this usually means coordinating the domain, the Tomcat context root, and any Apache forwarding rules so the visible address matches the real deployment. When those layers are aligned, your Java app is easier to maintain, easier to update, and less likely to break after a release.
If you are deploying WAR, JSP, or servlet applications on managed Java hosting, always verify the context path, test the public URL after each update, and make sure the application generates links that match its actual mounted location. That small check can prevent many common hosting issues.