When you host a Java application on a managed platform, the public URL is not always the same as the folder name, WAR file name, or application name you see in Plesk. In a Tomcat-based setup, the URL depends on the context path, how the app server is configured, and whether Apache is forwarding requests to your private JVM. If you want users to open the application at the right address without confusion, it helps to understand how deployment path, context root, and public URL work together.
In ITA’s Java hosting environment with My App Server, you can run a private Apache Tomcat / JVM inside your hosting account and map a Java app to a clean public URL. This is especially useful for JSP, Servlet, and WAR-based applications where the default Tomcat path is not the best user-facing URL. In many cases, you can keep the internal application structure unchanged while presenting a different public address through Plesk, Apache, or the Tomcat context configuration.
How public URLs work in a Java hosting setup
A Java application usually has two sides of addressing:
- Internal app location – where the app is deployed inside Tomcat or your private JVM.
- Public URL – the address visitors type in the browser, such as https://example.com/app.
These two values can be the same, but they do not have to be. For example, a WAR file named shop.war is often deployed as /shop in Tomcat. If you want the application to open at the root of the domain, such as https://example.com/, the context must be adjusted.
In a hosted environment, the public URL is commonly shaped by one or more of the following:
- The Tomcat context path
- The WAR file name or deployed application name
- Apache reverse proxy or forwarding rules
- Plesk domain and subdomain configuration
- Custom virtual host or app server settings
If one of these layers is inconsistent, the app may still work, but users may land on the wrong path, see redirects to an unexpected URL, or get 404 errors after login or form submit.
Understand the difference between path, context root and URL
Path
The path is the folder-like part after the domain name in a URL. For example, in https://example.com/shop/products, the path is /shop/products.
Context root
The context root is the base path where the Java app is mounted in Tomcat. If the context root is /shop, the app usually responds under that address and its subpaths.
Public URL
The public URL is the final browser address that users access. In many hosting setups, this is the URL you want to present in links, redirects, emails, and API callbacks.
Example:
- Deployed app name: myapp.war
- Tomcat context root: /myapp
- Public URL: https://example.com/myapp
If you rename the WAR file or change the context configuration, the public URL changes too unless Apache or Plesk maps it separately.
Typical ways to map a Java app to a public URL
1. Use the WAR file name as the context
This is the simplest Tomcat behavior. If you deploy app.war, Tomcat often serves it at /app. This is useful for quick testing and small applications, but it may not be ideal for a clean brand URL.
Best for:
- Testing environments
- Internal tools
- Simple applications where the path is acceptable
2. Set a custom context root
Many Tomcat setups allow you to define the context path manually. This gives you control over the public URL without changing the application code. You can map the app to a path such as /portal, /billing, or /api.
This is often the preferred approach when you want a predictable public address and you do not want to rely on the WAR file name.
3. Map the app to the domain root
If the application should open at https://example.com/ with no extra path, the app usually needs to be deployed as the root context. In Tomcat, that means the app is mounted at /.
This is common for:
- Main websites built on JSP or Servlet technology
- Customer portals
- Single-app domains
Be careful: root mapping is convenient, but it can conflict with other web content on the same domain if Apache or the control panel already serves static files or another site.
4. Use Apache to forward traffic to Tomcat
In managed hosting, Apache often sits in front of Tomcat. Apache can receive the public request and pass it to the Java app server. This is useful when you want Tomcat to stay private while Apache handles the public-facing domain.
This pattern can help when you want:
- Cleaner domain mapping
- SSL termination at the web server layer
- Static files served by Apache while Java handles dynamic requests
- Better separation between public site and internal app server
How to choose the right public URL for your Java app
The right mapping depends on how the application is used and what visitors expect. Use these practical rules:
- Use the root domain if the Java app is the main website.
- Use a dedicated path if the app is one part of a larger site.
- Use a subdomain if the application should be clearly separated, such as app.example.com.
- Keep the internal context simple if the app uses redirects, login flows, or callbacks.
For example:
- Main web app: https://example.com/
- Customer admin panel: https://example.com/admin
- Java API: https://api.example.com/
In a Java hosting and Plesk environment, using a subdomain can be cleaner when you want the app server isolated from the main website. A dedicated path is practical when the app should live under the same brand domain and share login or navigation with the rest of the site.
Steps to map a Java app to the correct public URL in My App Server
Step 1: Decide the desired public address
Choose the exact URL users should open. Write it down before deployment. For example:
- https://example.com/
- https://example.com/app
- https://app.example.com/
This helps you avoid later changes in links, redirects, and application configuration.
Step 2: Check how the app is deployed in Tomcat
Look at the deployed application name, WAR file name, and current context root in the My App Server / Tomcat settings. If the app is named myapp.war, it may already be exposed as /myapp.
If the app is deployed through a custom configuration, check whether the context path is defined manually. In many cases, that is the place where the public URL starts to take shape.
Step 3: Verify Apache or Plesk routing
If Apache is in front of Tomcat, confirm whether the web server is proxying or forwarding requests to the app server. In a managed hosting control panel, the domain may point to Apache first, and Apache may then pass selected requests to your Java app.
Make sure these settings match the intended URL:
- Domain name or subdomain
- Document root or virtual host target
- Reverse proxy target, if used
- HTTPS certificate coverage for the chosen hostname
Step 4: Update application URLs and redirects
Even if the server mapping is correct, the application itself may still generate old or relative URLs. Review:
- Login redirects
- Form submission URLs
- Links inside JSP templates
- API callback URLs
- Base href or application root settings
If the app was built for /app but is now hosted at /, hardcoded links may break. If the app uses a framework or custom configuration, update the base path accordingly.
Step 5: Test the final browser behavior
Open the target URL in a browser and test the full flow:
- Landing page loads correctly
- Static resources load without 404 errors
- Login and logout work
- Session does not bounce to the wrong address
- Forms and redirects stay within the intended URL
Also test with and without www if your domain supports both forms. If one version redirects to the other, make sure the Java app is aware of that final host name.
Common mistakes when mapping a Java app to a URL
Hardcoded context path in the application
Some apps assume they will always run under a fixed path such as /myapp. If you later move the app to root or another subdomain, these assumptions may break links, cookies, and redirects.
WAR file renamed without checking the URL
Changing the WAR name often changes the default context path. If you rename shop.war to store.war, the public path may also change from /shop to /store unless a custom context is configured.
Apache and Tomcat do not match
If Apache forwards requests to Tomcat but the forwarding rules still point to an old path, users may see 404 errors or be redirected to the wrong location. Always verify both layers after deployment.
Application uses absolute URLs generated for the old location
Relative links are often safer than hardcoded absolute paths inside a hosting environment. If your app changes from /app to /, absolute links built for the older context can fail.
Missing HTTPS awareness
If SSL is handled at Apache or the control panel, Tomcat may still think the request is plain HTTP unless headers are passed correctly. This can affect redirects and cookie security flags.
Recommended URL patterns for different Java app types
JSP website
If the Java app is a public website built with JSP, the cleanest option is usually the root domain or a simple branded path.
- Preferred: https://example.com/
- Alternative: https://example.com/site
Servlet-based app
Servlet apps often work well under a dedicated context root, especially if they are part of a larger shared domain.
- Preferred: https://example.com/app
- Alternative: https://app.example.com/
Private admin panel
For administrative tools, a separate subdomain can make the structure clearer and easier to manage.
- Preferred: https://admin.example.com/
- Alternative: https://example.com/admin
Java API
For API endpoints, a dedicated subdomain is often easier to document and consume.
- Preferred: https://api.example.com/
- Alternative: https://example.com/api
How this works in a managed hosting control panel
In a hosting control panel like Plesk, the domain, application server, and web server settings are usually managed in one place. In ITA’s My App Server setup, you can use a private Tomcat instance inside your account and control the service through the panel.
That gives you a practical balance:
- Separate Java runtime for your app
- Choice of Java version where available
- Simple service control from the panel
- Deployment of WAR, JSP, and servlet applications
- Flexible path mapping for public URLs
This model is well suited for small and medium Java applications that need controlled deployment and a predictable public URL, without requiring a complex enterprise stack.
Checklist before you publish the URL
- Confirm the intended public URL
- Verify the Tomcat context root
- Check whether the WAR name affects the path
- Review Apache or proxy routing
- Make sure SSL covers the final hostname
- Update app-generated links and redirects
- Test login, session and form submission
- Check both www and non-www behavior if relevant
FAQ
Can I map a Java app to the domain root?
Yes, if the hosting setup allows the app to be deployed as the root context. This is common when the Java application is the main website. You should still verify that no other site content conflicts with the same domain.
Does the WAR file name always define the URL?
Not always. In standard Tomcat behavior, the WAR name often becomes the default context path, but custom context settings or Apache forwarding can override that.
Can I use a subdomain for my Java app?
Yes. A subdomain such as app.example.com is often a clean choice for a standalone Java application or admin panel. It can make routing and maintenance simpler.
Why does the app open at one URL but redirect to another?
This usually happens when the app has hardcoded base URLs, old redirect settings, or proxy configuration that does not match the current public address.
What should I check if static files return 404 errors?
Check whether the app context changed, whether the resource paths are relative to the new URL, and whether Apache or Tomcat is serving the files from the expected location.
Can My App Server host a private JVM for my application?
Yes. ITA’s Java hosting with My App Server is designed to run a private JVM and Apache Tomcat inside your hosting account, which is useful for controlling the app runtime and public URL mapping in a managed environment.
Conclusion
Mapping a Java app to the right public URL is mostly about aligning three layers: the Tomcat context, the Apache or control panel routing, and the URLs generated by the application itself. In a managed Java hosting setup with My App Server, you can usually keep the deployment flexible while presenting a clean, stable address to your users.
If you plan the public URL early, verify the context root after deployment, and test redirects and resource paths carefully, you can avoid the most common URL problems in Java hosting. That is especially important for JSP, Servlet, and WAR applications where the browser address should stay simple and predictable.