When you deploy a JSP application on a hosting platform, the public URL is usually determined by two things: the application’s context path and the web server routing in front of Tomcat. If the app is not reachable at the address you expect, the issue is often not the JSP code itself, but how the WAR file, context root, and Apache/Tomcat configuration are mapped.
On managed Java hosting with a control panel such as Plesk, this process is usually simpler than on a fully manual server. In a setup like My App Server, you can run your own Apache Tomcat or private JVM inside a shared hosting account, choose a Java version, and control how the application is deployed. That makes it practical for JSP hosting, servlet hosting, and small to medium Java applications that need a clean public URL without complex server administration.
How public URL mapping works for JSP applications
A JSP application is typically deployed as a web application archive, or WAR file, into Tomcat. Tomcat assigns the application a context path, and that context path becomes part of the public URL.
For example:
- If your app is deployed as myapp.war, the default context path is often /myapp.
- If the app is deployed as the root application, it can be served from /.
- If you set a custom context path such as /shop, users access it through https://example.com/shop.
In a typical hosting environment, Apache may sit in front of Tomcat. Apache handles the domain name and public requests, while Tomcat handles the Java application behind the scenes. In that case, the final URL depends on:
- the domain or subdomain configured in the control panel
- the Apache virtual host or proxy rule
- the Tomcat context path
- whether the app is deployed at the root or under a subpath
If any of these layers do not match, the app may open on the wrong address, show a 404 error, or redirect to an unexpected URL.
Understand the three common mapping options
1. Root application
This is when the JSP app is intended to open at the main domain, such as https://example.com/. This is useful for a primary website, a landing page, or a customer portal that should not have a visible application path.
In Tomcat, root deployment usually means one of the following:
- the WAR is named ROOT.war
- the application is configured with the / context
- the control panel or My App Server points the app to the domain root
2. Subpath application
This is the most common setup for JSP hosting. The app is accessed through a path such as /app, /portal, or /shop.
Example:
- Domain: example.com
- Context path: /shop
- Public URL: https://example.com/shop
This option is practical when one domain hosts several services, or when the main site is static or built in another system and the JSP app is only one part of the site.
3. Subdomain application
You can also map a JSP app to a subdomain, such as app.example.com or admin.example.com. This is common when the application should feel separate from the main website.
In this case, the public URL is usually the subdomain root, while Tomcat still serves the app from a context path behind the scenes. Depending on your setup, the user may see:
- https://app.example.com/
- https://app.example.com/login
- https://app.example.com/shop
Check the current context root before changing the URL
Before you remap a JSP application, confirm the current context root. In many hosting panels, the app name, WAR file name, or deployment folder determines the default URL.
Look for:
- the deployed WAR file name
- the application directory name
- the context configuration in Tomcat
- the domain or subdomain assigned in Plesk
- any Apache proxy or rewrite rules
If the application is deployed as myapp.war, but you expect it to open at /, the simplest explanation is that the context path is still /myapp. In a managed hosting environment, this can often be corrected in the application deployment settings without editing low-level server files manually.
How to map a JSP app to the right public URL in Plesk
When using Plesk with My App Server, the workflow is usually designed to make Java hosting easier for non-administrators. The exact screens can vary, but the logic is the same: connect the domain, select the Java application, then define where it should be served.
Step 1: Assign the correct domain or subdomain
Make sure the domain or subdomain is already added to your hosting account. If you want the app to open on a subdomain, create that subdomain first and verify that DNS is pointing correctly.
If the app should be on the main domain, confirm that the domain itself is linked to the hosting subscription and is active in the control panel.
Step 2: Deploy the WAR file or application package
Upload your JSP application as a WAR file or use the upload method supported by the service. My App Server is designed to support practical Java deployment inside a hosting account, so the app can be installed and managed without building a separate dedicated server environment.
Check that:
- the package upload completed successfully
- the application is listed as active
- the correct Java version is selected
- Tomcat or the private JVM service is running
Step 3: Set the context path
The context path is the most important part of public URL mapping. In many cases, you can set it directly in the application settings.
Use a clear and predictable path:
- / for the root application
- /app for a main business app
- /portal for a client portal
- /admin for administrative access
Avoid changing the context path too often, because internal links, bookmarks, callbacks, and hardcoded routes may break.
Step 4: Save and restart the Java service if needed
Some changes take effect immediately, while others require a restart of the Java service or Tomcat instance. In managed hosting, the control panel usually provides service control options so you do not need shell access for basic tasks.
If your app is still opening under the old path, restart the application service and clear the browser cache before testing again.
Step 5: Test the public URL
Open the exact address you expect users to visit. Test the home page, at least one internal page, and any JSP form or login screen that uses relative links.
Check the following:
- the page loads with HTTP 200
- static assets such as CSS and images load correctly
- forms submit to the expected endpoint
- redirects go to the correct host and path
Best practices for JSP context paths and public URLs
Use stable, human-readable paths
A good context path should be short and easy to remember. Choose a URL that clearly reflects the app purpose. This helps users, support teams, and SEO where applicable.
Keep the application path consistent across environments
If your development environment uses /app and production uses /, relative links and redirects may behave differently. Try to keep the same context path across test, staging, and live deployments when possible.
Prefer relative links inside JSP pages
Hardcoded absolute URLs can create problems if the context path changes later. Using relative paths or application-aware link generation helps keep the app portable.
For example, assets and links should ideally be generated in a way that respects the current application root instead of assuming a fixed domain and folder.
Watch for duplicate path segments
A common mistake is deploying an app under a path and also adding the same folder in the application code. For example, the app may already be available at /shop, but internal links point to /shop/shop/product.
Review your JSP includes, navigation menus, and redirect rules if the same path appears twice in the browser address bar.
Use subdomains when the app should behave like a separate service
If the application is a portal, dashboard, or internal tool, a subdomain often creates a cleaner public URL than a deep path. This also helps keep the main website structure separate from the Java application structure.
How Apache affects the final URL
In many hosting setups, Apache is used as the public front end. It can serve static files directly and forward Java requests to Tomcat. This is common in managed hosting because it combines convenient web serving with Java application support.
Apache can affect the public URL in several ways:
- it may pass requests to Tomcat under a specific path
- it may rewrite URLs for clean address handling
- it may redirect the domain root to a subfolder or application path
- it may serve a site from one directory while forwarding JSP requests elsewhere
If the URL you see in the browser does not match the Tomcat context path, check whether Apache rewrite or proxy rules are changing the request before it reaches the Java service.
Common problems and how to fix them
The app opens at the wrong path
This usually means the WAR file name or context configuration does not match the intended public URL. Rename the deployment package or adjust the context root in the control panel.
The app shows 404 at the public URL
Check whether the application is deployed, whether Tomcat is running, and whether the URL includes the correct path. A missing context path is one of the most common causes of a 404 in JSP hosting.
Static files load, but JSP pages fail
This may point to a servlet mapping problem, a deployment issue, or a mismatch between Apache and Tomcat routing. Review the app logs, the deployment status, and the context path settings.
Redirects send users to localhost or an internal address
Some applications generate redirects using hardcoded server names. Update the application configuration so redirects use the public domain rather than an internal hostname or local address.
CSS and image links break after moving the app
This often happens when the app was built for a different context root. Check whether the JSP pages use absolute paths that assume the application is always at the root or always under the same folder.
Practical examples
Example 1: Main site at the root domain
You want the JSP app to open at https://example.com/. In this case, deploy the app as the root application, verify the domain assignment in Plesk, and make sure Apache routes the domain root to Tomcat correctly.
Example 2: Customer portal under a subpath
You want the app at https://example.com/portal. Deploy the application with the context path /portal, test internal links, and confirm that login redirects and form actions keep the same prefix.
Example 3: Separate app on a subdomain
You want the app at https://app.example.com/. Create the subdomain, connect it to the Java hosting service, deploy the app as the root application for that subdomain, and test that all assets and redirects use the subdomain URL.
When to change the context path and when not to
Change the context path when the app is being moved to a new public location, when a cleaner URL is needed, or when you are separating services across different subdomains.
Avoid changing it unnecessarily when:
- the app is already indexed or bookmarked
- internal links and callbacks depend on the current path
- the app is stable and working correctly
- external integrations call a specific endpoint path
If you must change it, plan the update carefully and test every major page and integration point after deployment.
How My App Server helps with JSP hosting URL mapping
My App Server is useful in this scenario because it gives you practical control over Java hosting inside a regular hosting account. You can run your own Apache Tomcat or private JVM, choose from available Java versions, and manage the service through the control panel.
For JSP and servlet applications, this means:
- you can deploy WAR-based apps without full server administration
- you can assign an app to the desired domain or path
- you can keep a separate JVM for the application
- you can adjust the service when you need to change the public URL
This is especially useful for small and medium projects that need a predictable URL structure, but do not require enterprise clustering or complex high-availability architecture.
FAQ
Why does my JSP app open at /myapp instead of /?
Because Tomcat usually uses the WAR file name or deployment folder as the default context path. Rename the app to ROOT or change the context configuration if you want it on the domain root.
Can I map a JSP app to a subdomain?
Yes. A subdomain is a common and clean way to publish a Java application. You usually create the subdomain in the control panel, deploy the app there, and set the application as the root service for that subdomain.
Do I need to edit JSP files to change the public URL?
Not always. In many cases, the context path or domain mapping can be changed in the control panel or Tomcat settings. However, you may need to review links and redirects inside the app if they use hardcoded paths.
Why do images and CSS break after changing the URL?
This often happens because the app uses absolute paths tied to the old context root. Update asset references so they work with the new public URL.
Should I use a root domain or a subfolder for a JSP application?
Use the root domain if the JSP app is the main website. Use a subfolder if the app is one part of a larger site. Use a subdomain if the app should be separated from the main site but still remain easy to access.
What should I check if the app is not reachable after deployment?
Verify that Tomcat is running, the WAR is deployed, the context path is correct, the domain is assigned properly, and any Apache proxy or rewrite rules are pointing to the right place.
Conclusion
Mapping a JSP app to the right public URL is mostly a matter of aligning the domain, the Tomcat context path, and any Apache routing in front of the application. In a managed hosting environment with Plesk and My App Server, this is usually straightforward once you understand where the application is deployed and which path it should use.
If you set the context root carefully, keep URLs consistent, and test redirects and static assets after deployment, your JSP application will be easier to maintain and much more predictable for users.