If your Java app is deployed on a shared hosting account with a private JVM and Apache Tomcat, the public URL should be mapped carefully so users reach the application root, not the raw application files. In a managed hosting setup with Plesk and a Java hosting extension such as My App Server, this usually means choosing the right context path, making sure the Tomcat webapp name matches the URL, and checking how Apache forwards traffic to the Java service.
For UK websites, this is especially important when you want a clean public address such as https://example.co.uk/app or https://app.example.co.uk/ instead of a technical path like /myapp-1.0.0 or a server-specific internal route. The goal is to keep the public URL stable even when you update the Java build or restart the service.
How public URL mapping works for Java apps
In a Java hosting environment, the visible URL is usually controlled by three layers:
- Domain or subdomain - the hostname customers type into the browser.
- Context root - the path segment after the domain, such as
/,/app, or/portal. - Application server routing - Apache Tomcat or a proxy layer that sends the request to the correct Java application.
If these layers are aligned, the browser shows a clean public URL and the app loads correctly. If they are not aligned, you may see redirects to the wrong path, 404 errors, or a login page that keeps sending users back to an internal URL.
In a Plesk-based Java hosting platform, the public URL is often influenced by the app server installation, the deployed WAR file name, the virtual host configuration, and any Apache rewrite rules used to send requests into Tomcat.
Choose the right URL pattern for the app
Before changing server settings, decide what the public address should look like. The most common patterns are:
Root domain
Example: https://example.co.uk/
This is the cleanest option when the Java app is the main website. It is common for customer portals, internal dashboards, or small business applications hosted on a private JVM.
Subdirectory
Example: https://example.co.uk/app/
This is useful when the domain also serves static pages or another website. It is a good choice if you want the Java application to live alongside other content on the same hosting account.
Subdomain
Example: https://app.example.co.uk/
This is often the easiest option when you want a separate public entry point for the Java app. It keeps the application path simple and helps isolate the app from the main site structure.
In practice, many hosting customers prefer a subdomain for a Tomcat app because it reduces confusion around paths and makes future changes easier.
Map the context root in Tomcat
Tomcat uses a context root to decide which URL path serves which application. If the app is deployed as myapp.war, the default context path is often /myapp. That may be fine for testing, but it is rarely ideal for a public website.
To map the app to the right public URL, you usually need to control one of the following:
- The WAR filename
- The context configuration
- The reverse proxy or rewrite rules in Apache
For example:
ROOT.warusually maps to/portal.warusually maps to/portal- A custom context file can map an app to a different path
When using My App Server, check how the application was installed in Plesk and whether the chosen Tomcat service is already exposing the app under the expected context. In many cases, the simplest stable setup is to deploy the application under the exact path you want users to visit.
Steps to point a Java app to the correct public URL
Use the following practical approach when mapping a Java app to a public address in a managed hosting environment.
1. Decide the final public path first
Before touching the deployment, define the target URL. For example:
https://example.co.uk/for the whole sitehttps://example.co.uk/app/for an application sectionhttps://app.example.co.uk/for a separate app hostname
Do not deploy the app first and decide the URL later. Changing the public path after users start using the application can break saved links, callbacks, and bookmarks.
2. Match the deployment name to the context path
If the platform deploys a WAR file directly to Tomcat, the deployment name usually affects the public path. A file called portal.war often becomes /portal. If you want the root path, use the conventional root deployment name if supported by your setup.
For apps that must run under a subdirectory, keep the deployment name and the public path consistent. This helps avoid unnecessary redirects and makes maintenance easier.
3. Check Apache and proxy behaviour
On hosted Java environments, Apache may serve the domain and forward application requests to Tomcat or the private JVM. This is common when the control panel manages both web hosting and Java service routing.
Make sure Apache is not rewriting the URL in a way that conflicts with the Tomcat context. Typical issues include:
- Redirect loops between
/appand/app/ - Double path segments such as
/app/app - Static files loading from the wrong base URL
If your app uses relative links, test them carefully after deployment. A page that loads at the correct public URL can still break assets, forms, or API calls if the base path is wrong.
4. Configure the application’s base URL
Many Java applications have a setting for the public base URL. This may appear in:
- Application properties
- Environment variables
- Framework configuration files
- Deployment descriptors
Examples include login redirects, email links, OAuth callbacks, webhook endpoints, and absolute links inside the app. If this setting does not match the real public URL, users may be sent to the wrong address even though the server routing is correct.
5. Test with and without trailing slash
URL path handling can be sensitive to trailing slashes. For example, /app and /app/ may behave differently depending on your app and rewrite rules.
Test both versions and confirm that:
- The browser ends at the preferred canonical URL
- No duplicate content is exposed
- Form submissions still work
- Assets load correctly from CSS and JavaScript files
6. Verify HTTPS and canonical redirects
Most UK public websites should use HTTPS. If the Java app is behind Apache, verify that the redirect logic preserves the correct scheme and hostname. Otherwise, the app may generate insecure links or redirect to the wrong endpoint.
Also check that the app redirects all variants to one canonical URL, for example:
http://example.co.uk/tohttps://example.co.uk/https://www.example.co.uk/tohttps://example.co.uk/or the reverse, depending on your setup- non-canonical paths to the final chosen context root
Common URL mapping scenarios
Scenario 1: Java app at the root of the domain
If the Java application is the main site, map it to the root path. This is a common setup for:
- Customer portals
- Booking systems
- Small business web apps
- JSP-based sites
In this setup, the public URL should not show the application name in the path. Users should simply reach the site with the domain itself.
Scenario 2: Java app under a subdirectory
If the domain hosts several sections, place the app under a dedicated path such as /app or /portal. This works well when Apache serves a marketing site and Tomcat serves the Java part behind the scenes.
Remember to update any internal links, static asset paths, and application base URL settings to match the subdirectory.
Scenario 3: Java app on a subdomain
If you want a cleaner separation, use a subdomain. This is often the most manageable option for Tomcat hosting because it keeps the Java app independent from the main website structure.
For example, app.example.co.uk can point directly to the Java app, while www.example.co.uk continues to host the main website or landing pages.
How this works in a Plesk and My App Server setup
With a hosted Java service managed through Plesk, My App Server provides a practical way to install and manage a private JVM or Tomcat instance from the control panel. That makes it easier to handle deployment, service control, and Java version selection without dealing with server-level administration.
For public URL mapping, the important point is that the control panel, the Tomcat application, and the domain configuration should all agree on the same path. In a typical setup, you may:
- Install a Tomcat version from the available options
- Deploy the WAR or application files
- Assign the domain or subdomain in Plesk
- Set the context root or application name
- Test the final public URL in a browser
If you use a custom app server configuration, make sure the chosen path remains stable after updates. A new deployment should not unexpectedly change the public URL unless you intentionally change the context.
Practical checks before you go live
Use this checklist before publishing a Java app to users:
- The domain or subdomain points to the correct hosting account
- The Tomcat app is deployed under the intended context path
- The public base URL inside the app matches the real address
- Apache rewrite or proxy rules do not create duplicate paths
- HTTPS works without mixed-content errors
- Static assets load from the same public path
- Login, logout, and callback URLs are correct
- Old URLs redirect to the canonical address
If any item fails, fix the mapping before the app is shared with customers or search engines. Public URL mistakes are easier to correct before launch than after traffic starts using them.
Common problems and how to fix them
The app opens, but the path is wrong
This usually means the deployment name and the public URL do not match. Check the WAR name, context root, and any Plesk or Tomcat settings that define the app path.
The homepage loads, but CSS and JavaScript fail
This is often caused by relative paths that assume a different root. Update the app’s base path, fix resource references, or use a proper context-aware URL strategy inside the application.
The browser keeps redirecting in a loop
Redirect loops often come from conflicting Apache and application-level redirects. Review HTTPS enforcement, trailing slash handling, and any rules that rewrite / to /app.
Old bookmarks still open the wrong page
Set up a permanent redirect from the old path to the new canonical URL. This is especially important if you renamed the application or changed the context root after deployment.
The app works on the server but not from the public domain
Check DNS, domain assignment in the hosting control panel, and the Apache-to-Tomcat route. A service can be healthy internally while still being inaccessible through the public hostname.
Best practices for stable public URL mapping
To keep Java hosting predictable, follow these practices:
- Pick the final public URL before launch
- Keep the context root short and clear
- Prefer a subdomain if the app needs a clean separate entry point
- Use canonical redirects consistently
- Test after every deployment or Tomcat version change
- Document the chosen URL for future maintenance
These habits are especially useful in managed hosting environments where the platform handles much of the service setup for you. A simple, documented mapping reduces deployment risk and avoids unnecessary support requests.
FAQ
Can I map a Java app to the root domain in Tomcat?
Yes. In many setups you can deploy the app so it serves the root path. This is a common choice when the Java application is the main website.
What is the difference between a context root and a public URL?
The context root is the application path inside Tomcat, while the public URL is the full address users enter in the browser. The public URL includes the domain and the context root.
Why does my app show a different URL after deployment?
This usually happens because the deployment name, Tomcat context, or proxy configuration does not match the intended path. Check both the application settings and the hosting control panel.
Should I use a subdomain or a subdirectory for a Java app?
Either can work. A subdomain is often easier for separate applications, while a subdirectory is useful when the Java app is part of a larger site on the same domain.
Can Plesk control the Java app URL mapping?
Yes, in a managed hosting environment Plesk can influence the domain assignment and routing. With a Java extension such as My App Server, the control panel also helps manage the app server instance and deployment details.
Do I need to change links inside the app after moving the URL?
Often yes. Update base URLs, redirects, API callbacks, and any hardcoded links so they match the final public address.
Conclusion
Mapping a Java app to the right public URL is mainly about consistency: the domain, the Tomcat context root, the Apache routing rules, and the application’s own base URL should all match. In a UK hosting setup, a clean and stable address improves usability, avoids broken links, and makes future deployments safer.
With a managed Java hosting solution like My App Server in Plesk, you can keep the setup straightforward by choosing the public path early, deploying under the matching Tomcat context, and testing redirects and assets before going live. That is usually the most reliable approach for JSP, servlet, Tomcat, and private JVM hosting on shared hosting accounts.