When you host a JSP application, the public URL and the app path do not always mean the same thing. In a typical Tomcat or private JVM setup, the URL a visitor uses in the browser is mapped to a context root, a deployed application, and sometimes a reverse proxy or Apache rule in front of the Java service. Understanding that mapping is important when you move a JSP site from local development to managed hosting, especially if you use a control panel such as Plesk and a Java hosting service like My App Server.
This guide explains how public URLs, context paths, and application directories work together on JSP hosting. It also shows how to avoid common problems such as broken links, wrong redirects, and assets loading from the wrong location.
How the public URL is formed on JSP hosting
A public URL is the address that users type into the browser or click from a link. On JSP hosting, that URL usually points to a web application running inside Tomcat or another Java servlet container. The path part of the URL often maps to the application context, while internal file paths remain hidden on the server.
For example:
- Public URL:
https://example.com/shop/ - Context root:
/shop - Deployed app location: a WAR file or application directory inside the Java service
The browser only sees the public URL. The server uses that URL to route the request to the correct JSP application. If the context root changes, the public URL changes too unless you add a mapping or proxy rule to keep the old address working.
Public URL, context path and app path: the difference
These terms are often confused, but they refer to different layers of the hosting setup.
Public URL
This is the address visitors use on the internet. It may include the domain name, a subdomain, and a path. It is what search engines index and what users bookmark.
Context path
The context path is the part of the URL that identifies the application inside Tomcat. If your application is deployed as /shop, then the context path is usually /shop. In many JSP applications, this is also called the context root.
App path
The app path is the physical location of the application on the server or inside the hosting account. In managed hosting, you normally do not need to work with full system paths, but the app still lives somewhere on disk. That location contains JSP files, static assets, configuration files, and the deployment descriptor or packaged WAR content.
In short:
- Public URL = what the visitor sees
- Context path = what Tomcat uses to route the request
- App path = where the application files are stored
How this works in My App Server and Plesk
In the My App Server model, you can run your own Apache Tomcat or private JVM within a shared hosting account and manage it from the hosting control panel. This is useful for JSP hosting, servlet hosting, and smaller Java applications that need more control than plain static hosting.
Depending on the setup, the public site may be served through Apache, while Java requests are forwarded to Tomcat. Plesk and the My App Server extension help you manage the service, select a Java version, start or stop the app server, and deploy your WAR or custom application files.
In practice, the public URL is often tied to:
- the domain or subdomain configured in the control panel
- the Tomcat context root
- Apache or reverse proxy routing rules
- the deployment name of the application
This means that changing a deployment name or context root can change the public URL unless the hosting configuration keeps the same route.
Typical mapping examples
Below are common examples of how a browser URL maps to a JSP application.
Example 1: Domain root application
If the site is deployed to the root context, the visitor uses:
https://example.com/
In this case, the application is mounted at the domain root. This is common for a primary JSP site or a main application.
Example 2: Application under a subpath
If the app is deployed under a path, the visitor uses:
https://example.com/app/
The context path is /app. JSP links, form actions, and redirects should respect that context so the site works correctly whether it is hosted at the root or under a subdirectory.
Example 3: Subdomain for one Java application
If the application runs on a subdomain, the public URL may be:
https://app.example.com/
This is a common choice when you want a clean public address and a separate Java app environment. The app path still exists on the server, but users do not see it.
Why JSP links break when the context path changes
One of the most common JSP hosting problems is hardcoded links. If your pages assume the app is always at the server root, they may work locally but fail after deployment.
For example, a link like:
<a href="/images/logo.png">
points to the domain root. That works only if your application is mounted at the root and if the asset is actually available there. If the app is deployed under /shop, the browser will request https://example.com/images/logo.png instead of https://example.com/shop/images/logo.png.
To avoid this, JSP applications should use the context path dynamically, especially for internal links and assets.
How to build correct links in JSP
Use the application context instead of hardcoding absolute paths. This keeps your application portable across different hosting setups.
Use the context path for internal links
When creating links to pages, scripts, stylesheets, or images inside the app, include the context path from the request object or a framework helper if you use one.
Practical examples include:
- pages like
/shop/products.jsp - CSS files under the application path
- JavaScript files stored with the app
- form actions and redirects inside the same application
Keep static assets inside the same deployment
If your site depends on images, CSS, or JavaScript files, place them inside the application package unless you intentionally serve them from another location. That makes deployment easier and avoids broken references when the public URL changes.
Use relative paths carefully
Relative paths can work in simple JSP projects, but they can also become confusing when a page is nested in a folder. For example, a path like css/site.css may resolve differently depending on the current page URL. Using the context path is usually safer for hosted applications.
How redirects and forwards affect the public URL
Redirects and forwards are not the same thing, and they affect the browser in different ways.
Redirect
A redirect tells the browser to request a different URL. The address bar changes. This matters when you want users to land on a clean public URL after login, form submission, or app startup.
Forward
A forward happens inside the server. The browser does not see the internal destination. This is useful when one JSP or servlet hands off work to another page without changing the visible URL.
On JSP hosting, use redirects carefully if your application is not mounted at the root. A redirect to /login may fail if the app lives under /portal. In that case, the redirect should include the correct context path.
What happens when you deploy a WAR file
WAR deployment often influences the public URL directly. In many Tomcat setups, the deployment name becomes the context root unless it is overridden by a configuration file.
For example:
shop.warmay become/shopROOT.warmay become the domain root- a custom context configuration may map the app to another path
If your hosting plan or My App Server configuration lets you upload and manage a WAR file from the control panel, check the assigned application name and URL after deployment. A small change in file name can change the public URL.
How Apache and Tomcat can work together
In managed hosting, Apache often sits in front of Tomcat. Apache serves static content efficiently and forwards Java requests to the application server. This setup is common when you host JSP applications because it combines familiar web hosting behavior with Java runtime support.
When Apache is in front, the public URL may look simple, but the request may still be routed to Tomcat internally. The app path remains inside the Java environment, while Apache handles the external domain and path mapping.
This is important when you:
- set up clean URLs
- move a JSP app between subdomains
- keep old links working after a deployment change
- serve static assets outside the Java service
Best practices for JSP hosting paths and URLs
To keep your Java application stable and easy to deploy, follow these practical rules.
- Use the context path dynamically in JSP rather than hardcoding absolute URLs.
- Keep related assets inside the application unless you have a clear reason not to.
- Check the deployed context root after every WAR upload or app rename.
- Use a subdomain if you want a stable public address for one application.
- Test login, redirects, images, CSS, and JavaScript after deployment.
- Review any Apache or proxy rules if the public URL does not match the app path.
- Document the expected URL structure for each environment, including staging and production.
Practical checklist after deployment
- Open the public URL in a browser.
- Confirm the home page loads without missing CSS or images.
- Test at least one internal link.
- Submit a form and verify the redirect target.
- Check servlet and JSP routes under the expected context path.
- Make sure the app still works after a restart of the Java service.
Common problems and how to fix them
Problem: 404 on internal links
This usually means the link points to the wrong path or ignores the context root. Rebuild internal URLs using the application context path.
Problem: CSS or images do not load
The asset path may be hardcoded to the site root or to a local development structure. Move the files into the app and reference them with the correct context-aware path.
Problem: Redirect goes to the wrong place
A redirect may be missing the context path or may be using a hardcoded domain path. Review the redirect logic in your JSP or servlet and test it after deployment.
Problem: Application works locally but not on hosting
Local development often runs at a simple root context such as /. On hosting, the app may be deployed under a subpath or subdomain. Always test using the actual public URL structure from the hosting control panel.
Problem: Old links stop working after renaming the app
Changing the WAR name or context root can change the public URL. If the old URL must remain active, add a redirect or keep a stable deployment name.
How to choose the right URL structure for a JSP app
The best URL structure depends on the application type and how you want to manage it in your hosting account.
- Use the domain root for the main site or the primary JSP application.
- Use a subpath for a secondary app or an internal tool under the same domain.
- Use a subdomain when you want a clean and separate public entry point.
In a managed hosting environment with My App Server, the choice also depends on how you want to deploy, restart, and control the Java service from Plesk. A stable path structure makes support easier and reduces mistakes during updates.
FAQ
Is the public URL the same as the app path?
No. The public URL is what users see in the browser. The app path is the location of the application on the server. The context path sits between them and determines how requests are routed.
Why does Tomcat use a context path?
Tomcat uses the context path to identify which application should handle a request. This allows one server to host multiple JSP or servlet applications under different paths or subdomains.
Can I change the public URL without changing the app code?
Often yes. If your hosting setup supports it, you can change the context mapping, use a subdomain, or configure Apache or proxy routing. However, internal links should still use the context path so the application remains portable.
What happens if I deploy a WAR file with a new name?
In many Tomcat setups, the WAR file name becomes the context root. That means renaming the WAR may also change the public URL unless you configure a fixed mapping.
Do I need to hardcode full URLs in JSP files?
No, that is usually not recommended for internal resources. Use the application context path for internal links and reserve full URLs for external destinations or special cases.
Does this apply to servlet applications too?
Yes. JSP, servlet, and mixed Java web applications use the same basic context path and URL routing rules when deployed on Tomcat or a similar Java container.
Summary
On JSP hosting, the public URL is only the visible part of the routing chain. Behind it are the context path, the deployed application, and the hosting layer that connects Apache, Tomcat, or a private JVM. If you manage your Java application through a control panel such as Plesk with My App Server, keeping these layers aligned is the key to stable deployment.
Use context-aware links, check the deployed path after each release, and verify redirects and static assets after any URL or context change. That approach helps keep JSP hosting predictable, easier to support, and less likely to break during updates.