When a JSP application is deployed on shared hosting, the public URL is usually determined by the document root, the Tomcat context path, and any Apache or Plesk routing that sits in front of the Java service. In practice, the “right” URL is the one that matches how your app is deployed and how the browser reaches it without exposing internal file paths or requiring manual redirects after every release.
On an ITA Java hosting account using My App Server, you can run a private Tomcat instance or JVM inside your hosting account, choose a Java version, and control the service from Plesk. That setup is well suited for JSP hosting, servlet hosting, and small to medium Java applications where you need a predictable public address such as https://yourdomain.co.uk/app or https://app.yourdomain.co.uk/. The main task is to map the deployed application to the intended public URL and keep that mapping stable across updates.
How JSP public URL mapping works
A JSP application can be published in different ways, and each method affects the visible URL. The most common factors are:
- Domain or subdomain — for example, example.co.uk or app.example.co.uk.
- Context root — the part of the path that identifies the application in Tomcat, such as /, /myapp, or /portal.
- Document root or web root — where static and web application files are served from in the hosting account.
- Reverse proxy or Apache routing — sometimes Apache is used to forward requests to Tomcat or to rewrite public paths.
- Default application settings — Tomcat may treat a WAR file name or deployment directory as the context path unless you override it.
If your goal is a clean public URL, you need to decide whether the application should live at the root of a domain or under a path. For example:
- Root mapping: https://www.example.co.uk/
- Path mapping: https://www.example.co.uk/shop/
- Subdomain mapping: https://shop.example.co.uk/
Each option is valid. The best choice depends on how the app is structured, whether it is the main website or only one part of a larger site, and how you want future releases to behave.
Choose the URL structure before deployment
The cleanest deployments start with a clear target URL. Changing the public address later can affect links, sessions, login flows, and external integrations. Before uploading a JSP build, decide whether the app should:
- replace the main website at the domain root,
- run in a separate folder under the same domain,
- run on a dedicated subdomain, or
- be mapped behind Apache rules to a custom public path.
When to use the domain root
Use the root path if the JSP application is the main site and should open immediately when someone visits the domain. This is common for company portals, small business applications, and internal tools that have a single public entry point.
Example:
- https://example.co.uk/
In Tomcat, this usually means deploying the app as the root application or configuring the context so that it is not exposed under an extra folder name.
When to use a subdirectory
Use a subdirectory when the JSP app is part of a larger site or when you want to keep multiple applications under one domain. This is a practical choice if you have separate areas such as:
- /portal/
- /admin/
- /shop/
- /member-area/
This approach makes it easier to organise links, but the app must be aware of its context path. Hardcoded links to / can break unless they are built relative to the application root.
When to use a subdomain
A subdomain is a good option if the JSP app should behave like a separate service while still remaining under the same brand. This is often useful for:
- customer portals,
- testing and staging environments,
- admin dashboards,
- small Java services that need a separate URL.
Example:
- https://app.example.co.uk/
Subdomains can simplify routing because the app can often live at the root of that subdomain, which avoids extra path prefixes in JSP links and form actions.
Map a JSP app to the correct public URL in My App Server
In a managed hosting environment with Plesk and My App Server, the usual workflow is to install or activate the Java service, select the Tomcat or JVM version you need, and then point the application to the desired public path. The exact interface may vary slightly depending on the version of the extension and the application layout, but the logic is the same.
Step 1: Confirm the target domain or subdomain
Make sure the domain is already set up in your hosting account and resolves correctly. If you want to use a subdomain, create it first in the control panel and confirm that it points to the right hosting space.
Check:
- DNS is set correctly,
- the domain or subdomain is active in Plesk,
- the SSL certificate is installed if you want HTTPS,
- the hosting account has the necessary Java service enabled.
Step 2: Choose the deployment location
Upload the WAR file, JSP application, or compiled web app to the Java application area used by My App Server. If you are using Tomcat-style deployment, the name of the application package can influence the context path.
Typical examples:
- app.war may become /app
- ROOT.war may become the domain root
- a configured context may point to /portal or another custom path
If your app must open at the root URL, confirm that nothing else is already occupying that path, such as a default site, another app, or Apache content.
Step 3: Set or verify the context path
The context path is what Tomcat uses to identify your application in the browser. If the context path is wrong, the app may still run, but at the wrong URL.
Common patterns include:
- Root context: the app appears at /
- Named context: the app appears at /myapp
- Custom context: the app appears at a chosen path such as /billing
If you are managing the app through Plesk, look for the application mapping, deployment settings, or Java service configuration. If you are using a custom app server setup, the context may be defined in the deployment structure or in Tomcat configuration files.
Step 4: Align Apache and Tomcat routing
In many hosting setups, Apache receives the public request first and then forwards it to Tomcat. If Apache and Tomcat do not agree on the intended path, the browser may see redirects, 404 errors, or an unexpected default page.
Check for:
- rewrite rules that send traffic to the wrong folder,
- conflicting redirects from old releases,
- default index files that override the Java app,
- proxy rules pointing to an outdated backend path.
If the app should open at /, Apache should not serve a static page first unless that is intentional. If the app should open under a folder, make sure the Apache path and Tomcat context path match the same public URL.
Step 5: Test with a fresh browser session
After deployment, open the URL in a private browser window and test the intended path directly. This helps you spot cached redirects, old cookies, and stale asset paths.
Test:
- the home page,
- login and logout,
- form submissions,
- static assets such as CSS, JS, and images,
- links generated inside JSP pages.
How to map the app to the root URL
Mapping a JSP app to the root URL is often the most user-friendly option, but it must be done carefully so that Tomcat does not expose the application under an extra folder name.
Recommended approach
- Deploy the app as the root application if your setup supports it.
- Use a root-friendly WAR name or deployment structure.
- Remove any conflicting default content from the domain root.
- Ensure internal links use the application base URL rather than hardcoded host paths.
Example:
- Public URL: https://www.example.co.uk/
- Application should not require /app or another extra folder to load.
Common problems with root mapping
- An old index.html file still exists in the document root.
- A previous deployment left a redirect in place.
- Tomcat is running the app under a named context instead of the root context.
- Apache serves static content before the Java backend receives the request.
If the domain opens the wrong page, clear the old file or adjust the routing so the Java application is the primary handler for the domain root.
How to map the app to a custom path
A custom path is useful when you want the application to live inside a larger website or when you need a distinct URL for a specific function. In this case, the path itself becomes part of the public address and must be kept stable.
Example: app under /portal
If your application should appear at https://example.co.uk/portal/, then all of the following should align:
- Tomcat context path is /portal,
- Apache forwards or rewrites requests for /portal,
- the app generates links relative to the /portal base,
- assets are referenced with the same context-aware path.
This avoids issues where pages load, but images or forms break because the application assumes it is running at the root.
Best practice for JSP links
Inside JSP pages, avoid hardcoding absolute internal paths unless you are sure the app will always stay in the same location. A move from /app to /portal should not require you to rewrite every link manually.
Use context-aware paths for:
- navigation links,
- form actions,
- CSS and JavaScript file references,
- redirect targets after login or form submission.
How to map the app to a subdomain
Using a subdomain is often the simplest way to keep the public URL clean. Instead of placing the app under a folder, you assign it to its own hostname and let the app run at the root of that subdomain.
Example: app.example.co.uk
This setup works well when you want:
- a separate public entry point,
- clear separation from the main website,
- easier JSP link generation,
- less dependency on the main site’s folder structure.
In Plesk, the common process is to create the subdomain, attach the Java application to it, and configure the Tomcat context so the app loads at / on that subdomain. This is often more convenient than using a nested path on the main domain.
Using My App Server with Tomcat for URL mapping
My App Server is designed to give you practical control over Java hosting inside a managed environment. For JSP and Tomcat applications, the main advantage is that you can run a private service, choose the Java version, and manage deployment without needing a separate server administration stack.
For URL mapping, this means you can:
- deploy a WAR and expose it at the desired context path,
- run a dedicated Tomcat instance for a specific app,
- adjust service settings from the control panel,
- test different Java or Tomcat versions if the app requires them.
This is especially useful if your JSP application was built with a specific Java runtime in mind and the public URL must remain stable during releases.
Typical issues and how to fix them
The app opens at the wrong path
This usually means the deployment name or context path does not match the intended URL. Check the WAR name, the Tomcat context settings, and any Apache rewrite rules. If the app is named myapp.war, it may automatically appear as /myapp unless it is configured differently.
Static files load, but JSP pages fail
This can happen when Apache serves static content from one location while Tomcat handles JSP files from another. Confirm that the document root, proxy path, and Java app location are aligned. Also verify that your app is deployed completely and that the JSP engine is active in the selected Java service.
Links break after moving the app
This is usually caused by hardcoded paths. Update JSP pages to use the current context path rather than fixed absolute URLs. This is important if the application may move between /app, /portal, or the root URL later.
The old version still appears after deployment
This can be a cache, redirect, or deployment overlap issue. Clear browser cache, check for reverse proxy caching, and make sure the previous package was removed or replaced cleanly before publishing the new version.
HTTPS redirects do not go to the right place
If SSL is enabled but the redirect points to the wrong host or path, inspect the redirect rules in Apache or the application itself. A forced redirect to https:// should preserve the correct domain, subdomain, and context path.
Practical checklist before going live
- Confirm the final public URL.
- Make sure the domain or subdomain is active in the control panel.
- Deploy the WAR or JSP application to the correct Java service.
- Verify the Tomcat context path.
- Check Apache rewrite or proxy rules, if used.
- Test the URL with HTTPS.
- Open the site in a private window and verify pages, assets, and forms.
- Check that internal links are context-aware.
- Confirm the app still works after a restart of the service.
FAQ
How do I know whether my JSP app is mapped to the root URL?
If the app opens when you visit the domain without any extra folder in the address bar, it is mapped to the root URL. If you must type a path such as /app or /portal, then it is not at the root.
Can I change the public URL after deployment?
Yes, but it should be done carefully. Changing the context path or moving the app to another subdomain can affect bookmarks, external links, and internal redirects. If possible, add redirects from the old path to the new one.
Should I use a subdomain or a subdirectory for a JSP app?
Use a subdomain if the app should behave like a separate service. Use a subdirectory if it is one section of a larger website. For JSP hosting, a subdomain often makes routing simpler, while a subdirectory can be better for integrated sites.
Why does Tomcat show my app under a name I did not choose?
Tomcat often uses the WAR file name or deployment folder name as the default context path. If you want a different public path, adjust the deployment name or context mapping in the hosting control panel or Tomcat configuration.
Why do CSS and images stop working when I move the app?
That usually means file paths were hardcoded for the old URL. Update your JSP templates to use context-aware references so assets load correctly whether the app runs at /, /app, or another path.
Does My App Server support a private Tomcat instance?
Yes. The service is intended for managed Java hosting where you can install and control your own Tomcat or private JVM within the hosting account. It is suitable for practical JSP and servlet deployments that do not require complex enterprise clustering.
Conclusion
To map a JSP app to the right public URL, start with the intended domain structure, then align the Tomcat context path, Apache routing, and Plesk application settings so they all point to the same address. In an ITA hosting environment with My App Server, this gives you a practical way to run Java applications with a private Tomcat instance, choose the right Java version, and keep the public URL stable through deployment updates.
If the app is meant to be public at the root, deploy it as the root context and remove conflicting content. If it belongs under a path, make sure every link and asset reference is context-aware. If it should be separate, a subdomain is often the cleanest solution. With the URL mapping set correctly from the start, JSP deployments become easier to maintain and less risky to release.