If your JSP application is hosted on a managed hosting platform with Plesk and My App Server, connecting a domain usually means linking the domain name to the application’s public URL, confirming DNS points to the hosting account, and making sure Apache or Tomcat forwards requests to the right Java service. In most cases, the domain itself does not “run” the JSP app directly; instead, it is mapped to the Apache front end, which then passes traffic to your private Tomcat/JVM environment.
For UK customers, the same principles apply whether you are launching a new JSP site, moving an existing application, or replacing a temporary public path with a custom domain. The key is to align DNS, the hosting control panel, and the application’s base URL so visitors can open the site without using an IP address or internal port.
What “connecting a domain” means for a JSP application
For a JSP hosting setup, connecting a domain usually involves three layers:
- DNS — the domain must resolve to the hosting account’s public IP address.
- Web server mapping — Apache or the control panel must know which domain belongs to which site or virtual host.
- Application routing — the JSP app must respond correctly on the chosen domain, context path, or public URL.
If you are using My App Server, your JSP or servlet application may be running inside a private Tomcat instance managed from Plesk. In that case, the custom domain usually points to the Apache-facing URL, while Apache proxies or forwards traffic to the Java service. This keeps the application accessible through a standard domain such as example.co.uk instead of a raw Tomcat port.
Before you start
Check these items first to avoid delays during the domain setup:
- You have access to the domain registrar or DNS manager.
- The domain is active and not locked in a transfer state.
- Your hosting account is already created in Plesk.
- My App Server or your Java/Tomcat service is installed and running.
- You know whether the application should be available on the root domain, a subdomain, or a path such as /app.
If the application is still being deployed, it is often easier to connect the domain first and then deploy the WAR/JSP files into the correct document root or application directory.
Common domain connection options for JSP hosting
1. Root domain
This is the main domain, such as example.co.uk. It is the most common choice for business sites and public applications. When the domain is connected to the hosting account, visitors can open the site without typing a subdomain or directory path.
2. Subdomain
Examples include app.example.co.uk or java.example.co.uk. Subdomains are useful when you want to keep the JSP application separate from a main website, or when you are testing a new release before switching the primary domain.
3. Public path or context path
Some JSP applications are published under a path such as example.co.uk/shop or example.co.uk/myapp. This is common in Tomcat-based deployments, where the application context can be tied to a specific folder or WAR name. This option works well when you want the JSP app to coexist with a static site or another application on the same domain.
Step-by-step: connect a domain to a JSP application in Plesk
1. Point the domain to your hosting account
Update the domain’s DNS so it resolves to the public IP address of your hosting service. You can do this in one of two ways:
- Change nameservers to the provider’s nameservers if your hosting account manages DNS.
- Update A records at the registrar or DNS host if you manage DNS externally.
Typical records to check include:
- A record for the root domain.
- A or CNAME record for subdomains such as www or app.
- AAAA record if IPv6 is in use.
DNS changes can take time to spread, so the domain may not work immediately after the update.
2. Add the domain in the hosting control panel
In Plesk, the domain should be added as a website or domain alias, depending on your setup. This creates the correct virtual host entry so Apache knows which requests belong to your account.
If you are using a subdomain, make sure it is created under the correct parent domain and that its document root is linked to the intended application folder.
3. Install or confirm My App Server / Tomcat
For JSP hosting, the domain alone is not enough. The Java service must also be available. In the My App Server extension, you can usually install a ready-made Apache Tomcat version with a button, or configure a custom application server if your project requires it.
Make sure the service is:
- installed for the account
- running correctly
- using the Java version required by your app
- assigned to the right site or application root
If the Tomcat service is stopped, the domain may resolve correctly but still show an error page or gateway response.
4. Deploy the JSP application
Place your WAR file, JSP files, or application content in the location expected by the application server. Depending on your deployment model, this may be a Tomcat webapp directory or a managed deployment path inside the control panel.
When the app is deployed, check that:
- the start page loads through the domain
- static assets such as CSS and images load correctly
- JSP pages compile without errors
- session and form URLs use the public domain, not localhost or an internal host name
5. Configure the application base URL
Many JSP applications need a base URL setting in configuration files, environment variables, or application properties. Update this to match the public domain or subdomain you are using.
Examples of settings that may need review:
- absolute links inside templates
- callback URLs for login or payment flows
- redirect targets after form submission
- application properties that store the public host name
If the app was developed for a staging URL or an IP address, hardcoded links may break after the domain is connected.
6. Enable HTTPS
After the domain is mapped, install or renew the SSL certificate. For a public JSP application, HTTPS is strongly recommended, especially for login pages, customer portals, and any site that uses sessions or personal data.
Once the certificate is active, verify that:
- the domain redirects from HTTP to HTTPS if required
- there are no mixed content warnings
- the application works with the secure URL
If your application generates links internally, ensure it respects the secure scheme so users do not get redirected back to HTTP.
How domain mapping works with Apache and Tomcat
In a typical JSP hosting setup, Apache receives the request first because it handles the public domain. Apache then forwards the request to Tomcat or your private JVM service behind the scenes. This allows the application to be reachable on a normal domain and port 443 or 80, without exposing the Java process directly.
This approach is useful because it:
- keeps the public URL simple
- separates the web layer from the Java runtime
- lets you manage the application from Plesk
- supports common JSP and servlet hosting use cases
If you are using a custom app server or a manually uploaded Tomcat version, the routing rules must still match the domain you want visitors to use. When the public URL and the application context do not align, you may see blank pages, redirects to the wrong host, or 404 errors on JSP resources.
Connecting a domain to the root app versus a sub-path
Root domain deployment
Use the root domain when the JSP application is the main site. This is the simplest setup for customers and usually the easiest for SEO, branding, and user experience.
Make sure the Tomcat application context is configured so the site opens at the top level of the domain. If the app is installed under a folder name, you may need to adjust the context or rename the deployment package.
Sub-path deployment
If the JSP application should live under a path, the hosting setup must route that path correctly to the application. This is common for multi-site environments or when a static website and a Java app share the same domain.
Be careful with:
- trailing slashes
- relative links in JSP pages
- rewrites handled by Apache
- application-generated URLs that assume a different context path
When possible, test the exact public path before launching it to production users.
Typical problems and how to fix them
The domain still opens the old site
This usually means DNS is still cached, the domain points to the wrong IP, or the hosting account is not configured for that domain yet. Verify the A record, nameserver delegation, and the domain entry in Plesk.
You see a 404 or application not found
Check the application context, the deployment path, and whether Apache is forwarding requests to the correct Tomcat instance. A mismatched context path is one of the most common JSP hosting issues.
JSP pages load, but images or CSS do not
This often happens when the app uses hardcoded asset paths or relative paths that no longer match the new public domain. Review static file references and test them directly in the browser.
HTTPS shows a certificate warning
Make sure the SSL certificate covers the exact hostname being used, including www or subdomain variants. Also confirm that the domain points to the same hosting account where the certificate was installed.
The app works on one URL but not another
This is usually caused by inconsistent redirects, missing alias configuration, or an application that still expects a previous host name. Standardize the canonical URL and update the app settings accordingly.
Best practices for UK JSP hosting domain setup
- Use a clear public domain or subdomain that matches the app’s purpose.
- Keep DNS and hosting control panel changes in sync.
- Use HTTPS from the start for login, admin, and customer-facing pages.
- Avoid hardcoded local addresses in JSP configuration.
- Test the site after DNS propagation on multiple networks if possible.
- Document the chosen context path so future updates are easier.
- When moving from test to live, confirm redirects and canonical URLs.
For managed hosting environments, good domain setup also makes support easier. If you know which domain, subdomain, and Tomcat service are involved, troubleshooting becomes much faster.
Example scenarios
Example 1: Connecting a new business domain
You have a JSP application deployed through My App Server and want it to open on example.co.uk. You update DNS, add the domain in Plesk, assign the application to the site, install SSL, and confirm the start page loads over HTTPS. This is the standard setup for a public-facing Java website.
Example 2: Using a subdomain for a customer portal
You want the application to run on portal.example.co.uk. You create the subdomain, point its DNS to the hosting account, deploy the JSP app into the subdomain’s application path, and update the app’s base URL. This keeps the portal separate from the main website.
Example 3: Publishing the app under a path
You already have a main site and want the Java app available at example.co.uk/app. In this case, Apache must route that path to the correct Tomcat application, and the JSP app must generate URLs relative to the /app context. This is practical, but it needs careful testing.
When to use a domain alias or redirect
If you own several domain variations, you may want only one primary public URL while redirecting the others to it. For example, you might choose the non-www version as the main site and redirect www to it, or the other way around.
Use a redirect when:
- you want one canonical URL for SEO
- users may type different versions of the domain
- you are migrating from an old address
Use a domain alias when multiple hostnames should serve the same application without changing the visible URL structure.
FAQ
Do I need to point the domain directly to Tomcat?
No. In a managed JSP hosting setup, the domain usually points to the hosting account and Apache handles the public request. Tomcat runs behind that layer as the Java application service.
Can I use a UK domain such as .co.uk for a JSP application?
Yes. The extension of the domain does not change how JSP hosting works. What matters is that DNS, the control panel, and the application routing are configured correctly.
How long does it take for the domain to start working?
It depends on DNS propagation and caching. Some changes appear quickly, while others may take longer depending on the registrar, DNS TTL, and local network cache.
Can I use a subdomain instead of the main domain?
Yes. Subdomains are often a good choice for app portals, staging sites, and separate Java applications.
Why does the site open, but JSP features do not work?
This usually means the web server is reachable, but the application itself is not fully deployed or not connected to the correct Tomcat service. Check the app logs, deployment path, and Java service status.
Do I need SSL before launch?
It is strongly recommended. For any public JSP app, HTTPS should be enabled before users start logging in or submitting data.
Conclusion
Connecting a domain to a JSP application is mainly a matter of matching DNS, the hosting entry in Plesk, and the Tomcat or My App Server configuration. Once the domain points to the correct account and the application is deployed to the right context, the site can be published on a clean public URL instead of an internal port or temporary address.
For most UK hosting scenarios, the most reliable approach is to choose the final domain early, connect it in the control panel, deploy the JSP application to the correct path, and then finish with SSL and redirect checks. That gives you a stable setup that is easier to maintain, easier to troubleshoot, and ready for real visitors.