When you host a Java application on Tomcat, the public URL is usually made up of two parts: the domain path and the application path. Understanding how these work together is important when you want a clean URL such as https://example.com/app, when you map more than one domain to the same application, or when you move an existing JSP or servlet application into a managed hosting environment with Plesk and My App Server.
In Tomcat hosting, the domain points visitors to your hosting account, while the application path decides which Tomcat application is shown after the domain. In practice, this means you can keep the same application accessible under one domain, multiple domains, or a subpath under the main website, depending on how the service is configured.
How Tomcat uses domains and application paths
A browser request such as https://www.example.com/shop has two important parts:
- Domain - www.example.com
- Path - /shop
On Tomcat hosting, the domain usually resolves through DNS to the hosting account, and the path is matched to a deployed Java web application. The path can be the root of the site, such as /, or a subpath such as /app, /portal, or /admin.
In a managed hosting setup with Plesk and My App Server, this mapping is often handled inside the control panel. You select the domain, choose or install the Tomcat application, and then connect the application to the public URL you want to use.
Simple example
If Tomcat hosts a WAR file called myapp.war, the application may be available at:
- https://example.com/myapp
- https://www.example.com/myapp
If the application is configured as the root application, it may instead open at:
- https://example.com/
The exact URL depends on the domain mapping, the Tomcat context path, and the way the application server is configured in your hosting account.
What is a domain path in hosting terms?
In everyday hosting language, people sometimes say “domain path” when they mean the visible part of the URL that comes after the domain name. Strictly speaking, the domain is the host name, while the path is the route under that host.
For example:
- Domain: example.com
- Path: /store
- Full URL: https://example.com/store
On Tomcat hosting, this path is usually linked to the application's context path. That context path determines where the Java web application is published.
Common path types
- Root path - the application is available at /
- Subpath - the application is available at a folder-like URL such as /app
- Multiple paths - different applications can be published under different public paths on the same domain
This is useful when you want one domain for the main website and another path for a Java application, or when you want several Tomcat apps on the same hosting account.
How the domain points to the hosting account
Before Tomcat can serve an application, the domain must point to the correct hosting environment. This usually happens through DNS.
The common options are:
- A record - points the domain to the server IP
- AAAA record - points the domain to an IPv6 address if available
- CNAME record - points a subdomain to another host name
Once DNS is correct, the web server and Tomcat layer can receive requests for that domain. In a Plesk-based setup, the domain is then assigned to the hosting subscription or account, and the My App Server extension can connect the domain to the Java application.
If the domain does not resolve correctly, the application path will not matter because the browser will never reach the hosting account. If the domain resolves but the path is wrong, visitors may see a 404 error or the wrong application.
How the application path is created in Tomcat
Tomcat uses a context path to decide under which URL a web application is published. The context path is often based on the WAR file name or on the configured application name.
Examples:
- app.war may be deployed as /app
- shop.war may be deployed as /shop
- ROOT.war may be deployed as /
In My App Server, the application is managed from the hosting control panel, so you do not need direct access to a full enterprise application server setup. You can install a Tomcat version, choose a Java runtime, deploy WAR files, and control the service from Plesk.
Why the context path matters
The context path affects:
- the public URL used by visitors
- links generated inside the application
- redirects and login flows
- static resources such as CSS, JS, and images
If the application expects to run at / but is deployed under /app, internal links may break unless the app is configured for a non-root context. This is one of the most common issues when moving a Java web app into hosting.
How domain and application path work together
The final public address is the combination of the domain and the Tomcat context path.
Typical combinations include:
- example.com + / = https://example.com/
- example.com + /app = https://example.com/app
- app.example.com + / = https://app.example.com/
- app.example.com + /portal = https://app.example.com/portal
This flexibility is useful in managed Tomcat hosting because you can keep different services separated while still using a clean public URL structure.
Practical usage patterns
- Main website on Apache, Java app on Tomcat - the website stays on /, while Tomcat runs under /app or a subdomain
- Single Java site - the application is mapped to the root path so the homepage loads directly
- Multiple applications - different Tomcat apps are published under different paths on the same domain
- Migration from a test URL - an app moves from a temporary path to the final public domain
Domain mapping options in a Plesk hosting environment
With Plesk and My App Server, the control panel usually gives you a simple way to connect a domain to a Java application. The exact steps may vary depending on the service configuration, but the logic is the same: the domain must be attached to the hosting account, and the application must be assigned to the desired path.
In many hosted Tomcat setups, you can:
- add or manage a domain in Plesk
- set the document root or application target
- deploy a WAR file
- assign the Tomcat version and Java version
- start, stop, or restart the service
For small and medium Java applications, this is often enough to run JSP, servlet, and WAR-based projects without needing a separate application server team or complex infrastructure.
Step-by-step: mapping a domain to a Tomcat application
1. Make sure the domain points to the hosting account
Check the DNS records for the domain. The domain should resolve to the hosting environment where your Plesk account is located. If you are using a subdomain, make sure its DNS record is set up too.
2. Add the domain in Plesk
Ensure the domain is listed in your hosting account. If you are using an addon domain or a subdomain, confirm that it is assigned correctly and that the hosting panel recognizes it.
3. Open My App Server
Use the Java hosting extension provided in Plesk to create or select your Tomcat environment. Choose the available Tomcat version that fits your application, or upload and configure a custom version if that is supported in your account setup.
4. Deploy the WAR file or application package
Upload your application archive and confirm the context path. If you want the app on the root URL, it usually needs to be deployed as the root application. If you want a subpath, make sure the package name or configuration matches that path.
5. Set the public path carefully
Decide whether the application should open at:
- / for the full root domain
- /app for a dedicated application path
- /something-else for a separate service
A path change may require a redeploy or a restart of the application service.
6. Test the final URL
Open the full URL in a browser and verify that:
- the page loads on the expected domain
- the path is correct
- static resources load without errors
- login, forms, and redirects work as expected
Common examples of domain and path setups
Example 1: application at the root domain
Use this when the Java app is the main website.
- Domain: example.com
- Path: /
- Result: https://example.com/
Example 2: Java app under a subpath
Use this when the main domain has other content and the Java app should be separated.
- Domain: example.com
- Path: /app
- Result: https://example.com/app
Example 3: app on a subdomain
Use this when you want a cleaner separation between website and application.
- Domain: app.example.com
- Path: /
- Result: https://app.example.com/
Example 4: multiple apps on one hosting account
You can publish more than one Tomcat application if your hosting plan and service limits allow it.
- example.com/shop
- example.com/admin
- example.com/api
This approach is practical for small platforms, internal tools, or separate application modules.
How Apache and Tomcat can work together
In many hosting environments, Apache handles the public web traffic and Tomcat handles the Java application. This is a common setup for JSP and servlet hosting.
In such a configuration:
- Apache receives the request for the domain
- Apache serves static files or routes the request onward
- Tomcat processes the Java application path
This arrangement makes it easier to combine traditional web content and Java apps under one domain structure. It also fits well with a hosted control panel environment where service management is simplified.
Typical problems and how to fix them
The domain opens the wrong site
This usually means the DNS, domain assignment, or hosting mapping is wrong. Check whether the domain points to the correct account and whether it is attached to the right hosting subscription in Plesk.
The application opens at the wrong path
This often happens when the WAR name or context path does not match the desired URL. Review the deployment name and the application configuration in My App Server.
Static resources return 404
If CSS, JavaScript, or images fail to load, the application may be assuming a different base path. Confirm whether the app expects root deployment or a subpath, and adjust the context path accordingly.
Redirects go to the old URL
Hardcoded redirects or cached routes can still point to a previous domain or path. Update the application configuration and clear caches if necessary.
HTTPS works on the domain but not on the application
Make sure the SSL certificate is installed for the correct domain or subdomain and that the application is being accessed through the secured host name. In a managed hosting panel, SSL is usually attached at the domain level, not at the Tomcat app level.
Best practices for clean Tomcat URLs
- Choose the root path only when the Java app should be the main site
- Use a subdomain if you want stronger separation between the main website and the app
- Keep application names short and clear when they become part of the public URL
- Check internal links before going live
- Test HTTP to HTTPS redirects if SSL is enabled
- Restart the service after making path or deployment changes
For Tomcat hosting on a managed platform, these practices help keep public URLs predictable and reduce deployment issues after going live.
When to use a custom application server setup
Some projects need a different Tomcat version, a custom JVM, or a hand-tuned application server setup. In My App Server, this can be useful when the application depends on a specific Java runtime or Tomcat release.
Custom app servers are generally best for compatibility requirements, not for building heavy enterprise clusters. For small and medium web applications, the goal is usually stable deployment, correct URL mapping, and simple control from Plesk.
FAQ
Can I use one domain for more than one Tomcat application?
Yes. You can map different applications to different paths, such as /app, /portal, or /api, if your hosting setup allows multiple deployments.
Can I make my Java app open on the main domain without a folder name?
Yes. That usually requires deploying the application as the root application, often by using a root context such as / or a ROOT deployment name, depending on the setup.
Do I need DNS changes for a path change?
Usually not. DNS is needed when the domain itself changes or must point to a different hosting account. Changing the application path is typically done in Tomcat or the control panel, not in DNS.
What is the difference between a subdomain and a path?
A subdomain is part of the host name, such as app.example.com. A path comes after the domain, such as example.com/app. Both can point to the same Tomcat application, but they are configured differently.
Why does my app work on one URL but not another?
The domain may be correct, but the context path may differ. Also check redirects, base URLs, and SSL settings. In many cases the application itself is built for a specific public path.
Can Tomcat hosting handle JSP and servlet applications?
Yes. Tomcat is suitable for JSP, servlet, and WAR-based Java web applications, especially in a managed hosting environment where the server, Java version, and service controls are available from the panel.
Conclusion
Domain paths and application paths work together to create the final public URL of a Tomcat application. The domain brings visitors to your hosting account, and the Tomcat context path decides which Java app they see. In a managed hosting environment with Plesk and My App Server, this makes it easier to run Java, JSP, and servlet applications with clear URLs and practical service control.
When you plan the mapping carefully, you get a cleaner site structure, fewer deployment issues, and a smoother launch. Always verify DNS, domain assignment, application context, and SSL together so the final URL works exactly as expected.