Before changing the domain of a live JSP site, review how the new public URL will affect Apache, Tomcat, DNS, HTTPS, redirects, session cookies, and any hardcoded links inside the application. In a managed hosting environment with Plesk and a Java hosting service such as My App Server, the domain change is usually straightforward, but a live JSP application can still break if the web path, SSL certificate, or Tomcat mapping is not updated in the right order.
This article explains what to check before you switch a running JSP site to a new domain, how to avoid downtime, and what to verify after the change. It is written for hosting customers using JSP hosting, Tomcat hosting, servlet hosting, or a private JVM on shared hosting with Plesk control panel access.
What changes when you point a live JSP site to a new domain
A domain change is not only a DNS update. For a JSP application, the public URL may be connected to several layers:
- DNS records that send the domain to the hosting server
- Apache virtual host settings for the domain and SSL
- Tomcat or My App Server mapping for the application path
- Application settings such as base URL, callback URL, and cookie domain
- Search engine indexing and redirects from the old domain
If any of these still point to the old domain, users may see login problems, mixed-content warnings, broken links, or 404 errors. In a JSP hosting environment, the safest approach is to review the full request flow before and after the cutover.
Check whether the application uses the domain in configuration
Start by finding every place where the old domain is stored inside the application or deployment settings. Common examples include:
Application configuration
- Base URL or public site URL
- Login redirect URL
- OAuth or SSO callback URLs
- Payment gateway return URLs
- Email links for password reset or verification
- API webhook endpoints
Many JSP applications store these values in a properties file, XML config file, database table, or environment-specific settings in the control panel. If the app generates absolute URLs, update them before switching the domain.
Hardcoded links in JSP pages or templates
Search the codebase for the old domain string and review:
- Absolute links in JSP files
- Static resources such as images, CSS, and JavaScript
- Canonical tags and Open Graph tags
- Form action URLs
- Download links
Where possible, use relative paths or application-aware URL generation instead of hardcoding the domain. This reduces the risk of missing a place during a domain change.
Session and cookie settings
If your app uses cookies tied to the old domain, logins may stop working after the change. Review:
- Cookie domain setting
- Secure and HttpOnly flags
- Session timeout behaviour
- Any custom session tracking logic
For most applications, a host-only cookie or a cookie set for the new domain is the correct choice. If the domain name changes completely, users may need to log in again.
Review Apache, Tomcat, and Plesk mapping before you switch
In a managed hosting setup, the domain often reaches Apache first, and Apache forwards requests to Tomcat or the private JVM. If you use My App Server in Plesk, check that the domain is mapped to the correct application and service.
Confirm the domain assignment in Plesk
Before DNS is updated, make sure the new domain is added to the hosting subscription or mapped to the right site. Review:
- Primary domain versus alias or parked domain
- Document root or public path
- Whether the domain should point to the existing JSP application or a new deployment
- Apache proxy or reverse proxy settings if used
If the site uses a public path rather than the root domain, confirm that the path is still correct after the change. A mismatch here can lead to the application loading under the wrong URL or returning a 404.
Check the Tomcat context path
For JSP hosting and servlet hosting, the context path matters. If the application is deployed as an external WAR or under a specific context, verify that the new domain points to the same context path or that the app has been updated to the new route.
Examples of things to review:
- WAR file name and deployed context
- Root application versus subdirectory deployment
- Rewrite rules or proxy rules that send requests to Tomcat
- Custom connector settings used by My App Server
If you use a private JVM through My App Server, confirm that the service is running and the application is loaded under the intended public URL before making the switch live.
Review Apache rewrite rules
Apache may contain rewrite rules that assume the old domain or redirect users based on the previous host name. Check for:
- Redirects from HTTP to HTTPS
- Redirects from www to non-www, or the reverse
- Canonical redirects to the old domain
- Rewrite conditions using the host header
A common issue is a redirect loop caused by old and new host rules conflicting with each other. Test the target URL carefully before you change DNS, especially if the site already has SEO redirects in place.
Prepare DNS changes in advance
DNS is often the visible part of the domain switch, but it should be the last step, not the first. Plan ahead so the new domain resolves correctly when users begin to visit it.
Lower the DNS TTL before cutover
If you control the DNS zone, reduce the TTL for the relevant records in advance. A lower TTL helps the new address spread faster once you update the records. Do this ahead of time so existing caches expire more quickly.
Verify the correct records
Check the record type you need for the new domain:
- A record for IPv4
- AAAA record for IPv6, if used
- CNAME record for aliases, when appropriate
Ensure the records point to the correct hosting endpoint used by the JSP application. If the domain will replace an existing live site, make sure the new DNS target matches the current hosting account and not a test environment.
Plan the propagation window
Even with a low TTL, some users may continue to resolve the old address for a short time. During this period, both the old and new domains should ideally serve a controlled response. That may mean keeping the old site active long enough to redirect users cleanly to the new URL.
Make sure HTTPS is ready before changing the public URL
For live web applications, HTTPS should be ready before the domain switch goes public. A missing or mismatched certificate will immediately affect trust and may block logins or form submissions.
Review the SSL certificate
Check that the certificate covers the new domain and any required hostnames, such as:
- example.com
- www.example.com
- any additional alias used by the application
If you are moving from one domain to another, the old certificate will not protect the new name unless it includes that domain. Install or renew the certificate before the change if possible.
Confirm HTTP to HTTPS redirects
When the new domain goes live, test both HTTP and HTTPS. Make sure:
- HTTP redirects to HTTPS correctly
- The redirect points to the new domain, not the old one
- There is no chain of redirects longer than necessary
- The final URL matches the certificate name
In Apache and Plesk setups, redirect order matters. A wrong redirect can send users in circles or expose the site with an invalid certificate path.
Check external integrations before the switch
Live JSP applications often connect to external services. If those services know your old domain, they may reject requests or send callbacks to the wrong place after the switch.
Common integrations to review
- Payment gateways
- Email verification systems
- OAuth providers such as Google or Microsoft
- SSO or identity providers
- CRM or ticketing webhooks
- Monitoring and uptime checks
Update all callback URLs, allowed redirect URIs, and webhook endpoints to the new domain. If an external service only allows a single URL, keep the old domain live long enough to redirect users and complete in-flight requests safely.
Review SEO and public visibility settings
If the site is public and indexed by search engines, domain changes can affect rankings, traffic, and trust signals. This is especially important when the JSP site serves content pages, documentation, or public-facing application routes.
Set up redirects from the old domain
Use permanent redirects from the old domain to the new one where appropriate. This helps users and search engines reach the right location and preserves most of the ranking value.
Review the following:
- Old domain to new domain mapping
- www and non-www behaviour
- Trailing slash consistency
- Path-level redirects for moved pages
Update canonical and sitemap references
After the domain changes, update:
- Canonical tags
- Sitemap URLs
- robots.txt references if they contain full URLs
- Structured data with absolute links
Also check your analytics tools and webmaster tools so the new domain is tracked as the primary site.
Test the new domain before going live
Before you announce the change, test the site using a staged or preview setup. In managed hosting, this can be done by using a temporary hostname, hosts-file testing, or a staging domain if available.
Functional tests to run
- Open the homepage under the new domain
- Navigate through key JSP pages
- Submit forms and confirm validation works
- Log in and log out
- Upload files if the app supports uploads
- Test downloads and email-triggered actions
Technical tests to run
- Check that the certificate is valid
- Verify redirect behaviour from HTTP and old domain
- Inspect response headers for the correct host
- Confirm static assets load without mixed-content warnings
- Review application logs in Plesk or Tomcat for errors
If My App Server is in use, also confirm service control status, startup success, and memory or resource usage after the domain mapping changes.
Recommended change sequence for a live JSP site
The following order reduces the risk of downtime:
- Inventory all URLs, configs, redirects, and external integrations that use the old domain.
- Lower DNS TTL in advance.
- Install or prepare the SSL certificate for the new domain.
- Update the application base URL, callback URLs, and cookie settings.
- Adjust Apache, Plesk, or Tomcat mapping if the public path changes.
- Test the new domain in a staging or preview setup.
- Switch DNS to the new host or mapping.
- Verify redirects from the old domain to the new domain.
- Monitor logs, errors, and user sessions after the change.
For many JSP hosting setups, this sequence is enough to keep the application stable during the move. The main goal is to ensure that the browser, Apache, and Tomcat all agree on the same public URL.
Common problems after a domain change
Old links still appear in pages
This usually means the application still stores the previous domain in templates, config files, or database content. Search the codebase and content tables for the old hostname.
Login stops working
Check cookie domain settings, session handling, and any SSO callback URLs. A domain switch often invalidates existing sessions, which may require users to log in again.
HTTPS warning or certificate mismatch
The certificate likely does not include the new domain, or the redirect goes to a hostname not covered by the certificate. Recheck the certificate and redirect path.
404 errors after switching
This can happen when Apache or Tomcat points to the wrong context path, when rewrite rules are stale, or when the application expects a different public path than the one now used by the domain.
Redirect loop
Review HTTP to HTTPS rules, www handling, and any canonical redirects. A loop usually means one rule is sending the request back to a host or scheme that another rule changes again.
When to keep the old domain active
It is often useful to keep the old domain active for a transition period. This helps with:
- SEO redirects
- Users with bookmarks
- Cached links in emails and documents
- Third-party integrations that have not yet been updated
During this period, the old domain should not serve duplicate content indefinitely. Instead, use a controlled permanent redirect strategy and update all systems as quickly as practical.
FAQ
Do I need to change anything inside Tomcat when I only change the domain?
Not always, but you should verify the domain-to-application mapping. If the public path stays the same and Apache already forwards correctly, Tomcat may not need a redeploy. If the URL structure changes, review the context path and rewrite rules.
Will changing the domain delete my JSP application data?
No. A domain change does not normally delete application files or database data. However, the site can stop working if URLs, certificates, or redirects are not updated correctly.
Should I update the application first or DNS first?
Update the application, SSL, and redirects first. Change DNS only after the new domain is ready to serve the site correctly.
What if the application uses absolute URLs in many JSP pages?
Search and replace carefully, then test the most important flows. If possible, refactor the app to use relative URLs or a central base URL setting to make future changes easier.
Can I use the same My App Server setup with a new domain?
Yes, in most cases. My App Server is designed for practical JSP hosting and Tomcat hosting inside a managed hosting account, so the same service can usually keep running while the public domain changes. The key is to update the mapping, SSL, and application settings together.
How long should I keep redirects from the old domain?
Keep them long enough for search engines, users, and external services to update their references. For a live public site, this is usually best handled as a long-term permanent redirect rather than a short temporary redirect.
Conclusion
Changing the domain of a live JSP site is safest when you treat it as a full public URL migration, not just a DNS update. Review application settings, Apache and Tomcat mapping, SSL, redirects, cookies, and integrations before the cutover. In a Plesk-based Java hosting environment with My App Server, this preparation helps you move the site with less risk, fewer broken links, and a smoother experience for users.
If you are planning a domain change for a JSP, Tomcat, or servlet application, the best practice is simple: verify the new URL path end to end, test it before publishing, and keep the old domain active long enough to redirect traffic cleanly.