When you host a Java web application, the public URL is usually made up of two parts: the domain path and the application path. The domain path is the part controlled by DNS, the virtual host, and your hosting panel. The application path is the context path used by Tomcat or your JSP application. Understanding how these two layers work together helps you point visitors to the right place, avoid redirect loops, and keep your JSP hosting setup easy to manage in Plesk.
On a managed hosting platform with My App Server, this matters because your application may run inside its own Tomcat instance or private JVM, while the website can still be reached through a domain, subdomain, or a specific folder URL. In practice, you decide whether users should open example.com, www.example.com, app.example.com, or a path such as example.com/shop. Tomcat then serves the application under its configured context path, such as /, /app, or /shop.
How the public URL is built
A public URL for a JSP application has three main parts:
- Domain name — for example
example.comorapp.example.com. - Path on the domain — for example
/,/shop, or/portal. - Application context path — the path under which Tomcat exposes your WAR or JSP app.
In a simple setup, these parts match directly. For example, a domain can point to one application, and the app can be deployed at the root path /. In other setups, the domain points to a website, and the application is deployed under a subpath such as /app. The control panel and Apache/Tomcat configuration determine how requests are routed.
Think of it this way:
- DNS tells the internet where the domain goes.
- Apache or the hosting proxy receives the request and forwards it.
- Tomcat serves the JSP/Servlet application under its context path.
Domain path vs application path
The domain path and the application path are related, but they are not the same thing.
Domain path
The domain path is what the browser shows before the application begins. It is controlled by the hostname and the part of the URL that leads to the application. Examples:
https://example.comhttps://www.example.comhttps://app.example.comhttps://example.com/shop
This layer is usually handled by domain configuration, DNS records, virtual hosts, and SSL settings in your hosting panel.
Application path
The application path is the context path used by the JSP or Tomcat app itself. Examples:
/for the root application/appfor an application deployed underexample.com/app/adminfor an admin module/storefor a shop application
This layer is managed by the application server. In Tomcat, the context path is commonly defined by the WAR file name, deployment settings, or the server configuration.
How they work together on JSP hosting
On JSP hosting, the browser request reaches the domain first, then the hosting stack forwards it to the Java application. The final URL depends on both routing layers.
Typical combinations include:
- Domain root to app root:
example.comserves the app deployed at/. - Subdomain to app root:
app.example.comserves the app deployed at/. - Domain subpath to app context:
example.com/shopserves the app deployed at/shop. - Domain root to subpath app:
example.comredirects or forwards to an app deployed at/app.
For a hosting company using Plesk and a custom Java extension such as My App Server, the cleanest setup is often one application per hostname or one application per domain root. This reduces confusion with static files, redirects, and relative links in JSP pages.
Common deployment patterns
1. Root domain to a single Java application
This is the most straightforward pattern. The domain points to one application, and the app runs at /. Users open https://example.com and land directly in the JSP app.
This works well when:
- the site is mainly the application itself;
- you want simple URLs;
- you do not need separate public paths for multiple apps.
2. Subdomain for the application
Another common pattern is to use a subdomain such as app.example.com or portal.example.com. The application still runs at /, but the hostname identifies the app.
Benefits:
- clear separation from the main website;
- easy SSL management;
- simple Tomcat context at root path.
3. Application under a subpath
Some sites use a shared domain with multiple parts, such as example.com/blog, example.com/shop, or example.com/app. In this case, the hosting platform or reverse proxy forwards only that path to the Java app.
This setup is useful when:
- a PHP or static site already exists on the root domain;
- you need a Java app alongside other content;
- you want one domain with separate application areas.
Be careful with relative links, redirects, and asset URLs. A JSP application deployed under a subpath must generate links that include the correct context path.
How My App Server fits into the routing flow
With ITA’s My App Server in Plesk, the Java application runs in its own managed environment inside the hosting account. This makes it practical to host JSP, servlet, and Tomcat-based apps without having to manage a separate server.
In this model, the flow is typically:
- The domain resolves via DNS.
- Apache or the hosting front end receives the request.
- The request is passed to the configured My App Server instance.
- Tomcat handles the application under the selected context path.
You can use a ready-made Java/Tomcat version or install a supported version with one click, depending on your account options. Other versions can be uploaded and configured manually where supported. This flexibility is useful when you need a specific Java version for a JSP or servlet application.
For small and medium applications, this approach gives you the practical benefits of private JVM hosting while keeping control inside the hosting panel. You can manage the service, choose versions, and deploy WAR-based applications without a full dedicated Java platform.
Examples of URL mapping
Here are a few practical examples of how the mapping works.
Example 1: Root deployment
- Domain:
example.com - Application context:
/ - Public URL:
https://example.com
This is the easiest setup for a standalone JSP website.
Example 2: Subdomain deployment
- Domain:
app.example.com - Application context:
/ - Public URL:
https://app.example.com
Use this when the app should be separated from the main website.
Example 3: Subpath deployment
- Domain:
example.com - Application context:
/portal - Public URL:
https://example.com/portal
This is common when multiple services share the same domain.
Example 4: Static site at root, Java app in a folder
- Root website:
example.com - Java app:
/app - Public URL:
https://example.com/app
In this case, the hosting panel or Apache configuration must route only the /app path to Tomcat, while the rest of the site remains on the main web stack.
What to check before pointing a domain to a JSP application
Before going live, make sure the domain and application path are aligned.
- DNS record points to the correct hosting target.
- Domain or subdomain is added in the control panel.
- SSL certificate is installed for the hostname you will use.
- Tomcat context path matches the intended public URL.
- Apache or proxy rules forward the correct path to the app.
- Application links use the right base path.
- Redirects do not create loops between
www, non-www, or HTTP/HTTPS.
If the application is deployed under a subpath, review how the app builds absolute and relative links. JSP pages that assume the app is always at / may break when moved to /app or /portal.
Practical steps in a hosting control panel
Although the exact interface can differ, the usual process in Plesk or a managed hosting panel is similar.
Step 1: Add or select the domain
Make sure the domain or subdomain exists in the account and is connected to the correct hosting subscription.
Step 2: Prepare DNS
Create or update the DNS record so the domain resolves to the hosting platform. If you use external DNS, confirm that the A record or CNAME is correct.
Step 3: Install SSL
Enable HTTPS before launch. The certificate should cover the hostname users will visit, including www or any subdomain you plan to use.
Step 4: Set up My App Server
Open the My App Server section in Plesk, choose the Java/Tomcat version, and start or configure the service. Use the version that matches your application requirements.
Step 5: Deploy the application
Upload the WAR file or application files according to the supported deployment method. Confirm the context path assigned by Tomcat.
Step 6: Map the public URL
Decide whether the app should be available at the root domain, a subdomain, or a subpath. Update routing, virtual host settings, or proxy rules accordingly.
Step 7: Test the final URL
Open the expected public URL and verify:
- the correct application loads;
- pages keep the right path when navigating;
- static assets such as CSS, JS, and images load correctly;
- forms submit to the right endpoint;
- login and logout redirects stay on the same domain.
Common issues with domain and application paths
Wrong app opens at the domain
This usually means the domain points to a different document root, proxy target, or context path than expected. Check the virtual host and Tomcat deployment settings.
404 errors on internal links
This often happens when the app was moved from / to a subpath, but the links still point to the old location. Update JSP links to use the application context dynamically.
CSS or images do not load
Asset URLs may be hardcoded to the root path. If the application is not deployed at /, those links can break. Use context-aware paths for resources.
Redirect loop between HTTP and HTTPS
Check whether both Apache and the application are forcing redirects at the same time. In a managed hosting environment, only one layer should handle the canonical redirect.
Works on a subdomain but not on the main domain
This often means the app is configured correctly for one hostname, but the main domain is still mapped to another document root or another service. Verify both hostname and path settings.
Best practices for JSP hosting URLs
- Use one clear public URL per application whenever possible.
- Prefer root deployment or a dedicated subdomain for simpler maintenance.
- If you must use a subpath, ensure the app is context-aware.
- Keep HTTPS enabled from the start.
- Align DNS, Apache, and Tomcat settings before launch.
- Test with both the domain root and any redirected version such as
www. - Document the intended public path for future updates.
These practices reduce support issues and make it easier to move or update the application later.
When to use a subdomain instead of a subpath
Both approaches can work well, but a subdomain is often easier for Java hosting.
Choose a subdomain if you want:
- a clean separation from the main website;
- independent SSL and routing;
- fewer problems with relative paths.
Choose a subpath if you want:
- one main domain for multiple sections;
- the Java app to live beside an existing site;
- shared branding under a single hostname.
For JSP and Tomcat applications, subdomains are usually simpler, while subpaths are useful when the application is just one part of a larger site.
FAQ
What is the difference between a domain path and an application path?
The domain path is the public URL structure controlled by the hostname and hosting routing. The application path is the Tomcat context path where the Java app is deployed.
Can I host a JSP application on the root of my domain?
Yes. If the app is deployed at context path /, users can access it directly at the domain root, such as https://example.com.
Can I use a subdomain for My App Server?
Yes. A subdomain such as app.example.com is a common and practical way to publish a JSP or Tomcat application.
Why do my links break after moving the app to a folder?
Because the app may still assume it runs at /. Update links, form actions, redirects, and asset paths so they respect the actual Tomcat context path.
Do I need Apache and Tomcat to use the same path?
They do not need identical configuration, but the routing must line up. Apache or the hosting proxy should forward the correct public path to the Tomcat application.
Is My App Server suitable for large clustered Java deployments?
It is designed for practical JSP, servlet, Tomcat, and private JVM hosting inside a managed hosting account. It is a convenient solution for small and medium applications, not a replacement for complex enterprise cluster architecture.
Conclusion
Domain paths and application paths must work together for a JSP hosting setup to function correctly. The domain determines how users reach the hosting account, while the Tomcat application context determines what they see after the request arrives. When these layers are aligned, your Java app is easier to deploy, easier to secure with SSL, and easier to maintain in Plesk.
With My App Server, you can manage Java hosting in a controlled hosting environment, choose a Tomcat or Java version, and publish your app under the right domain or path. The key is to plan the public URL first, then match DNS, hosting, SSL, and application configuration to that URL.