When you host a Java application with a public domain, you usually work with two different path layers: the domain path and the application path. These two parts are related, but they do not always mean the same thing. In a typical Plesk-based Java hosting setup with My App Server, understanding this difference is important if you want your site to open correctly on a clean URL, a subdirectory, or behind a reverse proxy-style configuration handled by Apache and Tomcat.
In simple terms, the domain points users to your hosting account, while the application path tells the web server which Java app should answer that request. If these paths are not aligned, visitors may see the wrong page, a 404 error, or your app may load only under an unexpected URL such as /app or /myapp.
How domain paths and application paths differ
A domain path is the visible part of the URL after the hostname. For example, in https://example.com/shop, the path is /shop. A subdomain such as app.example.com has its own hostname, but it can also have a path, for example https://app.example.com/orders.
An application path is the internal or external URL path where your Java application is deployed. In Tomcat hosting, this can be:
- the root path /,
- a context path like /app,
- or a custom mapping set through the control panel or web server configuration.
On Java hosting platforms, especially when using a shared hosting account with a private JVM or Apache Tomcat instance, the application path often depends on how the app is deployed. For example, a WAR file named myapp.war may normally open at /myapp unless it is configured to use another context path.
What happens in a Java hosting setup with My App Server
ITA’s My App Server integrates Java hosting into Plesk so you can install and manage a private Tomcat/JVM environment from the control panel. This is useful for JSP, servlet and WAR-based applications that need their own Java runtime instead of a generic shared setup.
In this setup, the request flow is usually:
- The visitor opens a domain or subdomain.
- Apache receives the request for that hostname and path.
- Apache forwards the request to the Java application service when the URL matches the configured mapping.
- Tomcat or the private JVM responds with the application content.
The key point is that the domain itself does not “run” the application. It only points to the hosting account. The application path tells the platform where the Java app is exposed. When both are configured correctly, the user sees the app directly on the intended public URL.
Common URL mapping patterns
1. Domain points to the application root
This is the cleanest setup. The site opens at the root of the domain, for example:
- https://example.com/
- https://app.example.com/
In this case, the Java application is configured to answer from /. This is often the best choice for a public-facing app because it keeps URLs simple and avoids extra path segments.
2. Domain points to a subdirectory application path
Sometimes the Java app is deployed under a subpath, such as:
- https://example.com/app
- https://example.com/orders
This can happen when the application is intentionally isolated under one path, or when multiple apps share one domain. In Tomcat, this may come from the WAR name, deployment settings, or explicit context configuration.
3. Subdomain points to a Java application
This is very common for hosted Java apps:
- https://portal.example.com/
- https://api.example.com/
Using a subdomain is often easier when the Java application should be separate from the main website. It also makes SSL, redirects, and maintenance cleaner.
4. Domain path is forwarded to a Java app mounted elsewhere
In some cases, Apache serves the main website and only a specific path is mapped to Tomcat, for example:
- https://example.com/shop → Java app
- https://example.com/ → static or CMS site
This setup is useful if you want one domain to host both a regular site and a Java module. However, it requires careful path handling so that links, assets, and redirects inside the application continue to work.
Why the mapping matters for Tomcat hosting
In Tomcat hosting, the application context path affects many parts of the app:
- generated links inside templates,
- redirect URLs,
- CSS, JS and image file paths,
- login/logout routes,
- API endpoints,
- session handling and callback URLs.
If the app expects to run at the root but is actually opened under /app, relative links may still work, but absolute links can break. The opposite can also happen: if the application is written for a subpath and you try to expose it at /, some routes may no longer match.
That is why the domain mapping and application path must be checked together during setup and after any move to a new host, new Tomcat version, or new public URL.
How to choose the right public URL structure
The best URL structure depends on how the Java app is used.
- Use the root of a domain if the Java application is the main site.
- Use a subdomain if the app should be clearly separate from the main website.
- Use a subdirectory if the Java app is just one section of a larger site.
For most Java hosting and private JVM use cases, a subdomain is often the simplest option. It avoids conflicts with a main website and makes it easier to manage a dedicated Tomcat app under Plesk.
Step-by-step: map a domain to a Java application
1. Check the domain or subdomain
Make sure the domain is added to the hosting account and points to the correct document root or hosting subscription. If you use a subdomain, confirm that it is created in Plesk and has the correct DNS record.
2. Confirm the Java service is active
Open My App Server in Plesk and check that the Java service or Tomcat instance is running. If the service is stopped, the domain may resolve correctly but the application will not respond.
3. Review the application deployment path
Check where the WAR, JSP or servlet application is deployed. If the app is meant to open at the root, confirm that the context path is set accordingly. If it should open under a subpath, verify the path name used by the deployment.
4. Match Apache routing with the app path
If Apache is used as the front-end web server, confirm that requests for the selected path are forwarded to the Java app. In a standard Plesk environment, this is usually handled through the Java extension and the hosting configuration. If you changed any custom rules, check that they do not override the app path.
5. Test the public URL
Open the domain in a browser and test both the main page and a few internal links. Pay special attention to:
- homepage loading,
- static assets such as CSS and JavaScript,
- forms and login pages,
- redirects after actions,
- API or AJAX endpoints.
6. Verify HTTPS and canonical URLs
If the site uses SSL, confirm that the Java application generates https:// links and not old http:// URLs. A mismatch between domain mapping and application path often appears first in redirects or mixed-content warnings.
Typical problems and what they mean
The domain opens, but the app shows 404
This usually means the domain is pointed correctly, but the Java application is not exposed at the path you requested. Check the context path, deployment name, and Apache forwarding rules.
The app works on one URL but not on another
This often happens when the application is deployed under a subdirectory and then accessed from the root, or the opposite. Review whether the app expects /, /app, or another path.
Static files fail to load
If CSS, JS or image files return 404, the application may be using absolute paths that do not match the current context. This is common after changing the public URL structure.
Redirect loops after login
Redirect loops can happen when the app thinks it lives on a different base URL than the one the browser uses. Check the configured public URL, proxy headers, and any hardcoded callback URLs.
SSL works on the domain but not in the app
This can occur if the application still generates links with the old scheme or hostname. Make sure the app’s public base URL matches the real domain and that all redirects use HTTPS.
Recommended setup patterns for Java hosting
For small and medium Java applications hosted on a shared account with a private JVM, these patterns are usually the easiest to maintain:
- Single app, own subdomain — best for a standalone service or admin portal.
- Main site on root, Java app on subdomain — best when a CMS or static site already uses the main domain.
- Multiple Java apps on different subdomains — useful when you need separate services without path conflicts.
- Java app under a subdirectory — suitable for a specific module inside a larger site, but requires more careful URL testing.
If you manage the app through Plesk and My App Server, the simplest approach is usually to keep each Java application on its own hostname when possible. That reduces the chance of path conflicts and makes deployment easier.
Practical examples
Example 1: Root domain for one Java app
You want example.com to open a Tomcat-based application. The domain points to the hosting account, the Java service is enabled in My App Server, and the app is deployed with the root context. Visitors open the site without extra path segments.
Example 2: Admin panel on a subdomain
You keep the main website on www.example.com and place the Java admin panel on admin.example.com. This keeps the application separate and makes it easier to manage SSL, access control, and redeployments.
Example 3: Java app under /app
A shared site already uses the main domain, so the Java module is deployed at example.com/app. Apache passes that path to Tomcat, and the app is configured to generate links under the same base path.
How to check whether the path is correct
You can usually confirm correct mapping by testing these points:
- The domain resolves to the expected hosting account.
- The Java service is running in My App Server.
- The requested URL matches the deployed app context.
- Internal links keep the same base path.
- Forms submit to the same public hostname and path.
- Redirects return to the same domain, protocol and application path.
If one of these fails, the problem is often not the Java code itself, but the URL mapping between domain and application.
Best practices for domain and application path setup
- Use one clear public URL per app whenever possible.
- Prefer a subdomain for standalone Java applications.
- Keep the app context path short and predictable.
- Test after every deployment, Tomcat version change or domain change.
- Update hardcoded base URLs if the public path changes.
- Check SSL and redirects after moving the app.
- Avoid mixing multiple apps under one path unless you really need it.
When to review the configuration in Plesk
Review your domain and application path settings whenever you:
- add a new domain or subdomain,
- install a new Java/Tomcat version,
- move a WAR file to a different context path,
- change the document root or web root,
- enable SSL,
- switch between root and subdirectory access,
- import an existing Java app from another host.
These changes often affect how Apache, Tomcat and the public URL work together. A small mismatch in the path can be enough to break the live site even if the app itself is healthy.
FAQ
What is the difference between a domain path and an application path?
The domain path is the public URL segment after the hostname, while the application path is where the Java app is deployed and exposed. They often overlap, but they are configured in different places.
Can I run a Java app on the root of my domain?
Yes, if the application and hosting configuration are set up for the root context. This is common for standalone websites and public services.
Can I host a Java app under a subdirectory like /app?
Yes. This is possible when Apache and Tomcat are configured to serve that path and the application is written to work under that context.
Is a subdomain better than a subdirectory for Java hosting?
For a separate Java application, a subdomain is often easier to manage. A subdirectory is useful when the Java app is part of a larger site.
Why does my app work locally but not on the public URL?
Local testing usually ignores hosting mappings. On the public site, the real hostname, SSL, Apache routing and Tomcat context path must all match.
Do I need to change anything if I move the app to another domain?
Usually yes. You should review the public base URL, redirects, SSL configuration and any absolute links or callback URLs inside the application.
Conclusion
Domain paths and application paths must work together for a Java hosting setup to behave correctly. In a Plesk environment with My App Server, the domain gives users access to your hosting account, while Tomcat and the Java service decide which application responds to the requested path. When you map the domain cleanly to the right application context, you get a more stable site, fewer path errors and a simpler deployment process.
If you are setting up a new Java app, start by choosing whether the app should live on the root domain, a subdomain or a subdirectory. Then verify the Plesk configuration, check the Tomcat context path, and test the final public URL with both HTTP and HTTPS. That approach usually prevents the most common hosting and URL mapping issues before they reach your users.