When a JSP application is hosted on Apache Tomcat, the public URL and the app path must work together. The public URL is what your visitors type in their browser, while the app path is the context under which Tomcat serves your application. If these two do not match, you may see broken links, wrong redirects, missing static files, or JSP pages that load only partly.
In a managed hosting setup with Plesk and My App Server, this relationship is especially important because your Tomcat instance, Java version, and deployment method can affect the final URL structure. For UK-based hosting customers, the goal is usually simple: make the application reachable at a clean public URL, keep internal paths stable, and avoid manual changes every time you update the app.
How public URLs and app paths relate in JSP hosting
A public URL is the address users see in the browser, for example https://example.co.uk/shop. An app path, also called a context path or context root, is the route under which Tomcat exposes your web application, for example /shop or /.
Tomcat uses the context path to decide how incoming requests are mapped to a deployed application. If your JSP app is deployed as a WAR file named shop.war, Tomcat will often serve it under /shop. If it is deployed as the root application, it may be available directly under /.
In practice, the public URL seen by the user combines:
- the domain name, such as example.co.uk
- the context path, such as /shop
- the internal routes used by JSP pages, servlets, CSS, JavaScript and images
For example:
- https://example.co.uk/shop/ → public URL for the application root
- https://example.co.uk/shop/login.jsp → a JSP page inside that app
- https://example.co.uk/shop/assets/app.css → a static resource inside the same app
If the browser requests the wrong path, Tomcat cannot find the correct resource. That is why path consistency matters during deployment, testing, and release updates.
What Tomcat means by context path
The context path is the part of the URL that identifies the web application within a Tomcat server. It is not the same as a filesystem directory on disk, although it may be related during deployment.
Common context path examples
- / for a root application
- /app for an application deployed as app
- /myportal for a named WAR or configured context
On JSP hosting, this matters because many links inside the app are often written as relative or context-based paths. If the app is moved from /app to /portal, links that were hardcoded may stop working.
In a Plesk-managed Tomcat environment, the context path can be influenced by how the app is installed, how the WAR file is named, and whether a custom app server configuration is used through My App Server.
Public URL structure in a managed hosting environment
In managed hosting, the public URL is usually built from the domain or subdomain assigned to the account and the context path of the Java application. The hosting panel handles much of the mapping, but the application still needs to generate links correctly.
A typical structure looks like this:
https://domain.tld/context/page.jsp
or, for a root deployment:
https://domain.tld/page.jsp
When a JSP application uses absolute paths incorrectly, it can accidentally point to the server root instead of the app root. This is a common cause of CSS or image files not loading after deployment.
Root deployment versus subpath deployment
A root deployment places the app at /, which often gives cleaner URLs. A subpath deployment places the app under a specific folder-like route, such as /shop or /portal.
- Root deployment: easier for user-facing URLs, but may require careful handling if multiple apps share the same domain
- Subpath deployment: better when one domain hosts multiple applications or when you want to isolate a specific service
For JSP hosting, subpath deployments are common when testing releases, running multiple applications, or separating an admin interface from a customer-facing site.
Why path consistency is important for JSP, servlet and Tomcat apps
JSP applications often include a mix of server-side pages, servlet endpoints, form submissions, and static files. All of these can depend on the correct base path.
If the public URL and app path do not match, you may see:
- broken stylesheet and JavaScript links
- images loading from the wrong location
- redirects pointing to an incorrect domain or folder
- session-related pages failing after login
- 404 errors on JSP pages that are actually deployed
Because Tomcat evaluates the context path before routing the request to your app, even a small mismatch can change the behavior of the whole site. This is especially relevant after a release update or when switching between test and live deployments.
How My App Server fits into JSP path management
With ITA My App Server, you can install and manage a private Tomcat or JVM instance inside your shared hosting account. This is useful when you need a Java hosting setup that is more flexible than standard static hosting, but still manageable through Plesk.
My App Server is practical for:
- JSP hosting
- Tomcat hosting
- servlet hosting
- private JVM hosting for small and medium applications
- WAR-based deployment
Because the app server runs under your account, path handling becomes something you can control directly from deployment and configuration. That includes the public URL exposed to users and the app path under which Tomcat serves the project.
Depending on the version and deployment method, you can:
- install a ready-made Tomcat version with a button
- upload a custom app server version and configure it manually
- control the service from the hosting panel
- align the domain or subdomain with the application context path
This setup is well suited for projects where you want practical control without managing a full enterprise Java platform.
How to align public URLs with app paths
To make sure the user-facing URL and the Tomcat context work together, follow a consistent deployment approach from the start. The exact steps may vary depending on whether you use a WAR file, an exploded application, or a custom app server configuration in Plesk.
1. Decide the target URL before deployment
Choose whether the app should be accessible at the root domain or under a subpath. For example:
- https://example.co.uk/ for the main site
- https://example.co.uk/app for a separate application
- https://app.example.co.uk/ for a subdomain-based service
Deciding this early prevents later changes in links, redirects and resource references.
2. Match the WAR name or context configuration to the desired path
If your Tomcat deployment uses a WAR file, its name often determines the app path. For example, shop.war usually becomes /shop. If you want root deployment, you may need a different configuration approach rather than relying on the WAR name alone.
If you use a custom context configuration, make sure it points to the path you actually want users to see.
3. Use context-aware links inside JSP pages
Instead of hardcoding absolute paths like /css/style.css, use the app context when generating links. This reduces path issues when the application is moved or redeployed under another route.
Common problem:
- Hardcoded URL points to the server root
- Application is deployed under /shop
- Stylesheets fail to load because the browser requests the wrong location
A context-aware approach avoids this mismatch.
4. Verify redirects after login and form submission
Many JSP and servlet applications use redirects after authentication, checkout steps, or profile updates. These redirects must point to the correct public URL and include the context path if needed.
If a redirect jumps to a missing page, check whether the application is sending users to:
- the domain root instead of the app root
- a path that no longer exists after deployment
- a route that differs between test and live environments
5. Test static resources separately
Always confirm that CSS, JavaScript, fonts and images load from the intended public URL. This is often the fastest way to detect path problems.
Check:
- homepage styles
- login page assets
- admin panel icons
- PDF downloads or file links
Typical path problems on JSP hosting
Path issues are among the most common deployment problems for JSP applications. They are usually easy to fix once you know where the mismatch happens.
Broken links after moving the application
If the app was moved from /app to /portal, any hardcoded links may still point to the old path. This affects JSP pages, servlet URLs and static file references.
404 errors for CSS or JavaScript
This often happens when the browser tries to load a file from the wrong base URL. The file may exist inside the application, but the reference points to the server root or another context.
Redirect loops
If login or session redirects are built with the wrong base path, users may be sent back and forth between two URLs. This can happen after a deployment change or when switching from HTTP to HTTPS.
App loads, but images do not
This usually means the main JSP pages are in the correct context, but asset paths are inconsistent. The HTML is served successfully, while file requests fail because they are outside the application path.
Best practices for UK JSP hosting projects
For UK hosting customers, the most useful approach is usually to keep the public URL simple and stable. Whether you use a domain, subdomain or folder-based route, the application should behave the same after each update.
- keep one clear canonical URL for the application
- avoid changing the context path unless there is a strong reason
- test the site after every release update
- use relative or context-based resource paths in JSP templates
- check both HTTP and HTTPS behavior if the site supports secure access
- verify that old bookmarks or redirects still resolve correctly
If you use Plesk with My App Server, it is helpful to review the service status, application configuration, and deployed version together. That gives you a clearer picture of how the URL mapping is behaving in production.
Examples of common deployment patterns
Example 1: Main site at the root
A business application is deployed to https://example.co.uk/. The JSP files, servlets and assets are all served from the same root context. This gives the cleanest public URL, but requires careful handling if other applications are added later.
Example 2: Customer portal under a subpath
A portal is deployed to https://example.co.uk/portal. The main website remains separate, and the Java application uses a dedicated context path. This is useful when the portal is updated independently from the main site.
Example 3: Subdomain for the Java app
A JSP application is published at https://app.example.co.uk/. This can help separate the Java service from marketing pages or CMS content while still keeping the URL easy to remember.
Checklist before going live
Before you publish or relaunch a JSP application, verify the following:
- the public URL matches the intended domain or subdomain
- the Tomcat context path matches the deployment plan
- all JSP links use the correct base path
- CSS, JavaScript and image URLs load correctly
- redirects point to live routes, not test routes
- the app behaves correctly after a service restart
- the selected Java version is compatible with the application
This checklist reduces the chance of path-related issues after deployment and makes release updates safer.
When to review the app path in Plesk
You should review the app path whenever you:
- deploy a new WAR file
- change the domain or subdomain
- move the application to a different context
- update Tomcat or the Java runtime
- switch between test and live versions
- add new static assets or servlet routes
In a managed environment, the hosting panel and My App Server give you practical control, but the app still needs to be aware of its own public base URL. That is why deployment and application code must be aligned.
FAQ
What is the difference between a public URL and an app path?
The public URL is the full browser address users visit. The app path is the Tomcat context under which the application is served. The public URL includes the app path, but they are not the same thing.
Why does my JSP app work on one URL but not another?
This usually means the application is using hardcoded links, redirects or resource paths that do not match the deployed context path. Review the base URL and update internal references to be context-aware.
Can I host a JSP app at the domain root?
Yes, but the deployment must be configured correctly. Root deployment can provide clean URLs, although some hosting setups prefer a named context path for easier management.
Why are my CSS and images broken after deployment?
The most common reason is that the browser is requesting files from the wrong path. Check whether the application is generating server-root paths instead of app-root paths.
Does My App Server support Tomcat-based JSP hosting?
Yes. My App Server is designed for Java hosting, Tomcat hosting, JSP hosting and servlet hosting through a private JVM setup managed from Plesk.
Should I use relative or absolute paths in JSP pages?
Use paths that remain stable when the application is redeployed. In many cases, context-aware links are safer than hardcoded absolute paths because they adapt better to context changes.
Do path rules change after a Java or Tomcat update?
The rules do not change, but the deployment behavior can. After an update, always confirm that the app still resolves the same context path and that all resources load correctly.
Conclusion
Public URLs and app paths must stay aligned for JSP hosting to work reliably. In Tomcat, the context path defines where the app lives, while the public URL is the address users see. When these two are configured consistently, JSP pages load correctly, redirects behave as expected, and static resources remain available after deployment.
For hosting customers using Plesk and My App Server, the practical approach is to choose the target URL early, deploy with a stable context path, and test links and resources after every release. That keeps Java hosting simpler, reduces path-related errors, and makes ongoing updates much easier to manage.