If you host a Java web application on a managed hosting platform, the public URL is usually made up of two parts: the domain name and the application path. In a Plesk-based Java hosting setup with Tomcat, these two parts work together to route visitors to the correct application without exposing the internal JVM or server structure.
For example, a visitor may open https://www.example.co.uk/app. In that URL, the domain points the request to your hosting account, while the path /app tells Apache or Tomcat which application or context to load. Understanding this split is important when you map a domain, add a subdomain, move a JSP application, or change the path of a deployed WAR file.
How the public URL is built
A browser request to a Java web application normally contains these elements:
- Protocol – usually http or https
- Domain name – for example example.co.uk or www.example.co.uk
- Application path – such as /, /shop, or /myapp
- Additional path – for example /login or /products/123
In a managed Java hosting environment, the domain is usually handled at the web server level, while the application path is handled by the Java application server, commonly Tomcat. The hosting control panel, such as Plesk, connects those layers so that the correct web space, domain, and Java service are used together.
Domain name versus application path
The domain name identifies where the request goes. The application path identifies what should answer the request.
- Domain name:
example.co.uk - Application path:
/or/app - Full URL:
https://example.co.uk/app
If you deploy a Java application to the root context, users access it directly from the domain, such as https://example.co.uk/. If you deploy it to a sub-path, users must include that path in the URL.
How this works in Java hosting with My App Server
In ITA Java hosting, My App Server is used to run a private JVM and manage Apache Tomcat inside a shared hosting account. That setup is useful for JSP, servlet, and small to medium Java web applications that need a separate Java runtime and straightforward deployment from the control panel.
When you configure a domain in Plesk and connect it to a Java application, the platform typically does the following:
- maps the domain or subdomain to your hosting subscription
- routes web traffic through Apache
- forwards application requests to Tomcat or the private JVM
- serves static files directly through the web server when appropriate
- keeps the application isolated within your hosting account
This makes it easier to host one or more Java applications without managing a separate dedicated application server instance outside the control panel.
What Tomcat does in the URL mapping
Tomcat handles the context path for the application. In simple terms, the context path is the part of the URL that tells Tomcat which app to serve.
/usually means the application is mounted at the root of the domain/appmeans the application is accessible under that path/storemeans a separate application can live under a different path
If a WAR file is deployed with a name such as shop.war, the context path may become /shop, unless it is explicitly configured otherwise. This is common in Tomcat hosting setups and is important when you want to control the final public URL.
Common ways domains and paths are mapped
There are several practical mapping patterns in a hosting control panel environment.
1. Main domain pointing to the application root
This is the simplest setup. The domain points directly to the Java application and the app is loaded from the root path.
- Domain:
example.co.uk - App path:
/ - Result:
https://example.co.uk/
This works well when the Java application is the main site and you do not need separate sub-sites on the same domain.
2. Domain pointing to a named application path
Sometimes the domain should open a specific application path instead of the root.
- Domain:
example.co.uk - App path:
/portal - Result:
https://example.co.uk/portal
This is useful if you host multiple sites under one account or if the Java app is only one part of a larger website structure.
3. Subdomain for a separate Java application
You can also use a subdomain for a different application.
- Domain:
app.example.co.uk - App path:
/or/app - Result:
https://app.example.co.uk/
This is a common choice when you want to separate a Java application from the main website while keeping the setup easy to manage in Plesk.
4. One domain, multiple applications under different paths
You can host multiple apps under one domain if the control panel and Tomcat configuration allow separate context paths.
https://example.co.uk/shophttps://example.co.uk/helpdeskhttps://example.co.uk/account
This can be useful for internal tools, portals, or staged deployments. Just make sure each application path is unique and does not conflict with another service or static directory.
How domain mapping works in Plesk
In a Plesk-based hosting environment, domain mapping is typically handled through the domain or subscription settings. The hosting platform defines which domain belongs to which account, then the Java service is linked to that same hosting space.
When you add or update a domain, the control panel usually manages:
- DNS destination, if the DNS zone is hosted on the platform
- document root or web root settings
- HTTPS certificate assignment
- web server configuration for Apache
- Java application routing to Tomcat/My App Server
In practice, the domain itself does not “know” about Java. Instead, the hosting stack maps the request through Apache to the correct backend service based on the configured site and path.
Document root and application path are not the same thing
Many users confuse the website document root with the Java application context path. They are related, but they are not identical.
- Document root: the file system folder served by the web server
- Application path: the public URL segment used by Tomcat
For static content, Apache may serve files directly from the document root. For Java requests, Apache often proxies or forwards to Tomcat based on the configured application path. If you move one without checking the other, links can break or the wrong content may appear.
What happens when the path is configured incorrectly
Incorrect mapping between the domain and the application path is one of the most common causes of Java hosting issues. Typical symptoms include:
- the domain shows a default page instead of the Java app
- the app works under one URL but not another
- static assets load, but JSP pages or servlets return 404
- HTTPS works on the domain root but not on the application path
- links inside the app point to the wrong context
These problems usually happen when the app was deployed under a different Tomcat context than the one expected by the domain configuration, or when the domain was changed without updating the application base URL.
Typical mismatch examples
- The application is deployed as
/myapp, but users are sent to/ - The domain points to
www.example.co.uk, but the app was configured forexample.co.uk - The WAR file name changed, which changed the Tomcat context path
- A reverse proxy or Apache rule rewrites the path unexpectedly
How to set up a domain for a Java application
The exact steps depend on your hosting account and control panel permissions, but the general process is the same.
Step 1: Make sure the domain is added to the hosting account
Confirm that the domain or subdomain exists in Plesk and is attached to the correct subscription. If the domain is not added, the platform cannot map it to the Java application.
Step 2: Check DNS points to the hosting service
Make sure the domain resolves correctly. If DNS is external, update the A, AAAA, or CNAME records as needed. If DNS is managed in the control panel, check that the zone is current and the records match the target setup.
Step 3: Enable the Java service in My App Server
Open the My App Server section and confirm that a Tomcat or private JVM instance is available for the account. Select the Java version you need if it is offered as a ready-made option, or upload and configure a custom app server if your setup requires it.
Step 4: Deploy the application to the correct context path
Upload the WAR file or application files and verify the context path. If your app should run from the root, make sure it is deployed as root. If it should run under /portal, make sure Tomcat and Apache are both configured to expose that path correctly.
Step 5: Confirm the base URL inside the application
Many Java applications store a base URL for redirects, login pages, and links. Update this value to match the real public domain and path, especially after changing from a staging URL to a live URL.
Step 6: Test HTTP and HTTPS
Check that the site works on both the domain root and the application path, and verify that SSL is applied correctly. If the certificate is installed for the domain but the application redirects to another host or path, users may see browser warnings or broken links.
Best practices for domain and path design
A good URL structure makes the application easier to maintain and helps avoid support issues later.
Use one canonical URL
Pick one primary public URL and redirect all other versions to it. For example, choose either https://example.co.uk or https://www.example.co.uk, then make sure the Java app and Apache rules follow the same pattern.
Keep application paths short and stable
Simple paths are easier for users and easier to support. Paths like /app, /portal, and /admin are generally clearer than deeply nested structures.
Avoid changing the context path after launch
Changing the path of a live Java application can affect bookmarks, SEO, API clients, and internal links. If you must move it, use redirects and update the application configuration at the same time.
Separate public and internal URLs
If you need an internal admin path, keep it distinct from the public user path. That makes it easier to control access and reduces accidental exposure of administrative tools.
Match redirects to the real deployment
Ensure that login redirects, callback URLs, and absolute links use the actual deployed domain and context path. This is especially important for applications that use authentication, forms, or external integrations.
Examples of common hosting scenarios
Scenario 1: New Java site on a main domain
You want your main domain to serve a small Java web application. The simplest setup is to deploy the app to the root context and configure the domain as the primary site.
- URL:
https://example.co.uk/ - Use case: company site, small portal, brochure site with JSP backend
Scenario 2: App under a separate path on the same domain
You already have a website, but you want a Java-based portal on the same domain.
- URL:
https://example.co.uk/portal - Use case: customer area, booking app, internal tool
Scenario 3: Subdomain for a Java application
You want a clean separation between the main site and the application.
- URL:
https://app.example.co.uk/ - Use case: client portal, test environment, service dashboard
Scenario 4: Multiple applications in one account
You host more than one Java app in the same managed hosting account.
- URL 1:
https://example.co.uk/shop - URL 2:
https://example.co.uk/helpdesk - Use case: separate modules, migration projects, small application suite
SSL and HTTPS considerations
Domain and application path mapping also affects HTTPS. The SSL certificate is issued for the domain name, not for the application path. That means the certificate secures example.co.uk and any paths under it, such as /app or /portal.
Important points to check:
- the certificate matches the exact domain or subdomain in use
- HTTP redirects point to the same canonical HTTPS URL
- the application does not generate mixed-content links
- hardcoded base URLs inside the app use
https
If the domain changes, update the certificate assignment in the control panel and confirm that Tomcat or Apache redirects are still correct.
SEO impact of domain and path choices
URL structure affects search visibility and indexing. While this article is mainly about hosting configuration, it is worth keeping SEO in mind when choosing domain and path mappings.
- Use a consistent canonical domain
- Avoid serving the same content on multiple URLs without redirects
- Keep application paths readable
- Do not change URLs unnecessarily after launch
- Make sure redirects preserve meaning and destination
For Java applications that generate pages dynamically, it is especially important to keep the base URL and context path aligned with the public address that search engines and users see.
When to check My App Server settings
Review your My App Server settings if you notice any of the following:
- the app is deployed, but the domain does not show it
- the app works only under a different path than expected
- you changed the Java version and the context behaves differently
- you uploaded a custom Tomcat setup and need to verify path handling
- Apache serves the domain, but the Java app is not loading
Because My App Server can run a private JVM inside your hosting account, the service configuration, Tomcat version, and application context should all be checked together when troubleshooting public URL issues.
Frequently asked questions
Can I host a Java application on the main domain and a second app on a subdomain?
Yes, this is a common setup. The main domain can serve one application, while a subdomain such as app.example.co.uk can serve another. Each one should be mapped to the correct hosting configuration and Tomcat context.
Does the SSL certificate cover the application path?
Yes. SSL secures the domain and everything under it, including application paths. You do not need a separate certificate for /app or /portal. You only need to ensure the certificate matches the domain name being used.
Why does my WAR file appear under a different URL than expected?
The WAR file name often influences the Tomcat context path. If the file is called shop.war, the application may be available at /shop. If you need a different public URL, adjust the deployment name or context settings in the hosting control panel.
Can I use the root path for a Java app in Plesk?
Yes, many Java applications can be mapped to the root path, especially when the domain is meant to serve that app as the main website. You should still verify that Apache, Tomcat, and the app’s own base URL are aligned.
What is the difference between the domain root and the application root?
The domain root is the top-level URL for the host name, such as https://example.co.uk/. The application root is the top-level path inside the Java application. In many setups they are the same, but not always. A Java app can also live under a sub-path like /portal.
Do I need to configure Apache manually?
Usually not. In a managed hosting environment, Apache configuration is typically handled by the platform and the control panel. You may only need to adjust settings if you are using a custom app server or a special routing requirement.
Troubleshooting checklist
- Confirm the domain is added to the correct hosting subscription
- Verify DNS resolves to the right destination
- Check that the Java service is running in My App Server
- Confirm the Tomcat context path matches the public URL
- Make sure HTTPS is enabled for the domain
- Review any redirects in Apache or in the application itself
- Test the root URL and the full path separately
- Check whether the WAR file name changed the context path
Conclusion
Domain paths and application paths work together to define the public URL of a Java application. In a Plesk-based Java hosting environment with My App Server, the domain points traffic to your hosting account, Apache handles the web layer, and Tomcat serves the Java application under the configured context path. When these layers are aligned, your site is easier to deploy, easier to secure with HTTPS, and easier to maintain.
If you are setting up a new Java hosting site, moving an existing app, or changing the public URL, always check the domain mapping, DNS, SSL, Tomcat context, and application base URL as one complete chain. That is the most reliable way to avoid broken links, wrong redirects, and path-related errors.