If your domain is not yet pointing to your JSP site, the issue is usually not with the JSP application itself, but with DNS, the web server mapping, SSL configuration, or a missing Apache/Tomcat connection in the hosting control panel. In a Java hosting setup with My App Server, the domain must resolve correctly before Apache can forward requests to the right Tomcat instance or private JVM. Until that happens, visitors may see an old site, a default page, or a browser error.
What “not pointing to the JSP site” usually means
This message can describe several different situations:
- The domain still opens a parked page, placeholder page, or another website.
- The DNS records are not updated, so the domain resolves to the wrong IP address.
- The domain is pointed correctly, but Apache is not linked to the JSP application.
- The SSL certificate is installed, but the HTTPS virtual host is not configured for the Java app.
- The site works on one hostname, but not on the main domain or www version.
- The Tomcat service is running, but the application context has not been deployed correctly.
In most cases, the fix is to verify the domain configuration step by step: DNS, hosting subscription, Apache mapping, Tomcat service status, and SSL settings.
How domain pointing works for JSP hosting
In a typical JSP hosting environment, the flow is:
- The domain resolves through DNS to the hosting server IP.
- Apache receives the HTTP or HTTPS request.
- Apache routes the request to the configured Java backend, often Tomcat through My App Server.
- Tomcat processes the JSP, servlet, or WAR application and returns the response.
If any part of this chain is missing, the domain may not show the correct JSP site. A DNS issue prevents the request from reaching the server. A web server issue prevents Apache from forwarding the request. A Tomcat or JVM issue prevents the app from responding. SSL issues can block the secure version of the site even if plain HTTP works.
Step 1: Check whether DNS is pointing to the correct server
The first thing to verify is the domain’s DNS configuration. If the domain name still points to an old IP address or a third-party service, the JSP site cannot appear on the correct host.
What to check in DNS
- The A record for the root domain points to the correct server IP.
- The www record points to the same server, either with an A record or a CNAME.
- There are no conflicting records left from a previous provider.
- The nameservers are set to the correct DNS service if you manage DNS elsewhere.
If you recently changed DNS, remember that propagation can take time. Some visitors may still reach the old target during that period, depending on TTL values and their local resolver cache.
Quick DNS validation
- Open the domain from a different network or device.
- Use a DNS lookup tool to compare the current IP address with your hosting server IP.
- Check both the main domain and the www version.
- Confirm that the domain name is spelled correctly in the DNS zone.
If DNS is not yet updated, wait for propagation or correct the zone records before troubleshooting Apache or Tomcat.
Step 2: Confirm that the domain is added to the hosting subscription
In a Plesk-based hosting environment, the domain must be attached to the right subscription or hosting account. Even if DNS is correct, Apache cannot serve the JSP site if the domain is not assigned properly.
Check the domain mapping in Plesk
- Make sure the domain exists in the correct subscription.
- Verify that the document root is set correctly for the application.
- Check whether the domain uses the intended hosting type.
- Confirm that the web server configuration was updated after changes.
If you created a new domain alias, subdomain, or addon domain, make sure it points to the same Java application directory or the intended virtual host configuration. A common mistake is to add the domain in DNS but forget to assign it in the control panel.
Step 3: Verify that My App Server or Tomcat is running
With Java hosting, the application backend matters just as much as the domain record. The domain may resolve correctly, but if the Tomcat service is stopped, misconfigured, or deployed to the wrong context, the site will not load.
What to confirm in the service control
- The Java service is enabled and running.
- The selected Java version matches your application requirements.
- The Tomcat instance is started successfully.
- The application package, WAR file, or JSP content is deployed to the correct app server.
- The app server path and context path match the expected URL.
In ITA’s My App Server setup, you can typically manage your own Apache Tomcat or private JVM inside the hosting account. That gives you practical control, but it also means the site depends on correct service status and deployment settings. If the service is stopped, the domain may still resolve, but the application will not respond.
Symptoms of a Tomcat-side problem
- The domain opens, but shows a 404 or 503 error.
- The root page loads, but JSP pages do not compile or execute.
- Static files work, but dynamic Java content fails.
- The application works on the internal Tomcat test URL, but not on the main domain.
Step 4: Check Apache virtual host and proxy configuration
In many JSP hosting environments, Apache acts as the front-end web server while Tomcat handles the Java application. If Apache is not configured to forward the domain to the correct backend, the domain may display a different site or the default Apache page.
What should be aligned
- The domain’s Apache virtual host points to the correct document root or proxy target.
- The HTTP and HTTPS virtual hosts are both configured consistently.
- The domain is routed to the appropriate Tomcat application instance.
- Any rewrite rules do not override the Java application path.
If you are using a Plesk extension such as My App Server, the integration usually handles much of this for you. However, manual changes, custom app servers, or old configuration files can create conflicts. If the domain still shows the wrong site after DNS is correct, the Apache vhost is a likely place to inspect.
Common Apache-related causes
- Another domain is assigned to the same IP and default vhost.
- The site was moved, but Apache config was not rebuilt.
- The host name mismatch exists between the certificate, vhost, and DNS name.
- A reverse proxy setting points to an old Tomcat port or internal address.
Step 5: Make sure the SSL certificate matches the domain
Because this article is in the SSL, DNS and Mail Problems category, SSL should be checked as part of the domain-pointing process. A valid certificate does not fix routing, but an SSL mismatch can make the site appear broken even when DNS is correct.
SSL checks to perform
- Confirm that the certificate includes the exact domain and the www variant if needed.
- Make sure the HTTPS virtual host is enabled for the correct hostname.
- Check that the certificate is installed on the same subscription or hosting service as the JSP app.
- Verify that no older certificate is still attached to the domain.
If the browser shows a certificate warning, visitors may think the domain is not pointing properly, even though the backend is reachable. In a managed hosting setup, SSL should be matched to the active domain and refreshed after domain changes, redirects, or service migration.
Typical SSL symptoms
- HTTP works but HTTPS fails.
- The browser shows a name mismatch error.
- The site opens on the wrong hostname after redirecting to HTTPS.
- Mixed content errors appear after deployment.
Step 6: Check the application path and context
Sometimes the domain is working correctly, but the JSP application is deployed under a different context path. In that case, the root domain may not load the app because the application is actually accessible under a subpath such as /app or /myapp.
What to verify
- The JSP application is deployed to the expected context.
- The root URL is mapped to the correct app if that is the intended setup.
- The application’s welcome file is present and valid.
- The WAR or unpacked application directory is in the correct location.
If you expect the site to open directly on the domain root, but the app is installed under a context path, you may need either a redirect, a rewrite rule, or a context configuration change. This is common with Tomcat hosting and private JVM setups where multiple apps may coexist under one account.
Step 7: Test for caching, propagation, and local resolution issues
Not every “domain not pointing” case is caused by the hosting account. Sometimes the issue is local cache, browser cache, or DNS resolver cache.
Practical checks
- Open the domain in an incognito window.
- Try a different browser.
- Flush local DNS cache if possible.
- Test from a mobile network or another internet connection.
- Use online DNS propagation tools to see the current record status.
If only one device shows the wrong site, the server may already be configured correctly and the remaining issue is cached data. If all locations show the wrong result, the issue is more likely DNS, Apache mapping, or app deployment.
Step 8: Review mail-related records if the domain is newly moved
When a domain is moved to a new hosting platform, it is common to update only the website records and forget the mail-related DNS entries. This does not usually stop the JSP site from loading, but it can create confusion if the domain also handles email and users report broader service problems.
What to verify for mail continuity
- MX records still point to the intended mail service.
- SPF, DKIM, and DMARC records are not broken by the move.
- The domain’s nameservers contain the full record set, not only the website record.
Keeping the DNS zone complete helps avoid a situation where the website is fixed but mail delivery breaks, or the domain appears partially moved and partially old.
Common causes and how to fix them
- Wrong DNS A record — Update the root and www records to the correct hosting IP.
- Incomplete propagation — Wait for DNS changes to spread, then retest.
- Domain not added in Plesk — Assign the domain to the right subscription and document root.
- Tomcat service stopped — Start the service and confirm the Java version and deployment.
- Apache vhost mismatch — Rebuild or correct the virtual host configuration.
- SSL certificate mismatch — Install a certificate that matches the active hostname.
- Wrong app context — Adjust the deployment path or redirect the root domain.
Recommended troubleshooting order
To save time, check the following in order:
- Confirm the domain’s DNS A record and www record.
- Verify that the domain is added to the correct hosting subscription.
- Check whether the JSP application is deployed and the Tomcat service is running.
- Inspect Apache routing or proxy settings.
- Validate SSL for both HTTP and HTTPS access.
- Test for browser cache, DNS cache, and propagation delays.
This order works well because it starts with external routing and ends with application-level details. If DNS is wrong, there is no need to spend time on Tomcat. If DNS is correct but the app is missing, there is no need to focus on the SSL certificate first.
Example scenario
A customer deploys a JSP application in My App Server and changes the domain to point to the hosting account. The DNS A record is updated, but the domain still opens the old site for several hours. After propagation, the root domain begins resolving correctly, but HTTPS shows a certificate warning and the app still does not load on the main domain. In this case, the likely causes are:
- The DNS change is still propagating for some resolvers.
- The SSL certificate has not been reissued for the new hostname.
- The Apache vhost is still linked to the previous site or default document root.
The fix is to confirm DNS resolution, reattach or reissue the certificate if needed, and verify that the Plesk domain configuration points to the correct Tomcat-backed application.
FAQ
How long does it take for a domain to point to a new JSP site?
It depends on DNS TTL values and resolver caching. In some cases it updates quickly, but full propagation can take longer. Even after DNS changes, the control panel and web server configuration must also be correct.
Why does the domain show a default page instead of my JSP application?
This usually means Apache is serving the default virtual host, or the domain has not been linked to the correct Tomcat application. Check the domain assignment in Plesk and the app deployment in My App Server.
Why does the site work on HTTP but not HTTPS?
This often indicates an SSL certificate or HTTPS virtual host issue. Make sure the certificate matches the domain and that the secure host is routed to the same JSP application.
Can a JSP application work if the domain DNS is not updated yet?
Not on the public domain name. You may still access the app through a temporary URL or internal test address, but visitors using the real domain will not reach it until DNS points to the hosting server.
What if the app works on a subdirectory but not the root domain?
Then the deployment context is probably different from the expected root mapping. You may need to adjust the context path, configure a redirect, or change the Apache routing setup.
Do I need to restart Tomcat after changing the domain?
Not always, but if you changed the application context, service configuration, or deployment files, a restart may be required. DNS-only changes usually do not require restarting the Java service.
When to contact support
Contact support if you have already verified DNS, domain assignment, Tomcat status, and SSL, but the domain still does not point to the JSP site. Useful details to provide include:
- The domain name and whether the issue affects root, www, or both.
- The expected destination IP or hosting subscription.
- Whether HTTP, HTTPS, or both are affected.
- Any recent DNS, SSL, or deployment changes.
- The Tomcat or My App Server version in use.
The more specific the information, the faster the support team can identify whether the issue is in DNS, Apache, SSL, or the Java application layer.
Conclusion
If your domain is not pointing to the JSP site yet, the problem is usually one of four things: DNS has not fully updated, the domain is not assigned correctly in the control panel, Apache is not forwarding requests to the Java backend, or Tomcat/SSL is not configured for the active hostname. In a managed JSP hosting setup with My App Server, the best approach is to check the domain path from DNS to Apache to Tomcat in that order. Once each layer is aligned, the domain should load the correct JSP application reliably.