If a JSP application suddenly stops working, the visible symptom is often a 404, 500, blank page, or a partially loaded site. The real cause may be a deployment issue, a Tomcat configuration problem, an application error, or a mismatch between the Java version and the app’s requirements. In a managed hosting environment, the fastest way to diagnose the issue is to check the app server status, the web server mapping, and the application logs in that order.
On a shared hosting account with Java support, such as a Plesk-based setup with a private Tomcat/JVM service, most broken JSP problems can be traced to one of a few areas: the application was not deployed correctly, the service is stopped, the context path is wrong, the app is calling missing files or libraries, or the server has run into resource limits. This guide explains how to find the cause step by step and how to narrow down whether the problem is in Apache, Tomcat, the JSP code, or the hosting environment.
What a broken JSP application usually means
A “broken” JSP application can show different symptoms depending on where the failure happens. The browser message is important because it often points to the layer that failed:
- 404 Not Found - the URL, context path, or Apache/Tomcat mapping is incorrect, or the app is not deployed.
- 500 Internal Server Error - the request reached the application, but the app or servlet/JSP code failed.
- Blank page or partial output - the page may be rendering, but a runtime error or missing dependency interrupts it.
- Timeout or gateway-style error - the app may be slow, hung, or not responding through the proxy/web server.
In JSP hosting, it helps to think in layers. First check whether the Java service is running. Then check whether the app is deployed. Then inspect the logs for the actual exception. That sequence saves time and prevents guesswork.
Start with the simplest checks
1. Confirm that the Tomcat or Java service is running
If you are using a private JVM or Tomcat service managed through a control panel such as Plesk, the application cannot respond if the service is stopped, restarting, or failing to start. Open the service control page and verify that the app server is active.
Check for:
- service status marked as running
- recent restart attempts
- startup failures after a deploy or configuration change
- messages about port conflicts, missing files, or Java errors
If the service does not start, the root cause is often in the startup logs rather than in the JSP page itself. Common causes include an invalid server.xml change, a bad library, an incompatible Java version, or an app that crashes during initialization.
2. Test the application URL carefully
Make sure you are testing the exact URL that should serve the application. A typo in the context path can look like an application failure when the app is actually fine. For example, a JSP app may be deployed under a specific path such as /myapp, while the root domain still points to a different web root.
Check the following:
- the domain name is correct
- the path after the domain matches the deployed context
- you are using the correct protocol, especially if HTTPS is required
- there is no old bookmark or outdated link pointing to a removed path
If the app works on one URL but not another, the problem is likely not the JSP code itself. It is more likely an alias, rewrite, document root, or context mapping issue.
3. Refresh the browser and clear cached error pages
Browsers and proxies can cache redirects, error pages, or static responses. A cached 404 or a stale redirect can make a fixed application still appear broken. Test in a private window or after clearing cache to avoid chasing a problem that no longer exists.
How to identify whether it is Apache, Tomcat, or the application
In a typical hosting setup, Apache serves the public website and forwards Java requests to Tomcat or another Java container. The visible error depends on which layer breaks first.
When the problem is likely Apache or routing
If static files such as images, CSS, or HTML load, but JSP pages return 404, the Apache-to-Tomcat mapping may be wrong. This can happen when the proxy rules, virtual host configuration, or application context path is not aligned with the deployed app.
Look for:
- incorrect rewrite rules
- bad proxy configuration
- missing context mapping
- the app deployed in a different directory than expected
If the domain opens the default hosting page instead of your Java application, Apache is probably not forwarding requests to the app server correctly.
When the problem is likely Tomcat or Java
If the request reaches the app server but returns a 500 error, Tomcat is running the application and the failure is usually inside the app, configuration, or runtime. This is especially true if the error page appears after login, form submission, or loading a specific JSP.
Typical signs include:
- HTTP 500 on specific pages only
- stack traces in the application log
- Java class loading errors
- missing libraries in
WEB-INF/lib - startup errors after changing Java version
When the problem is likely the application itself
If the app server starts normally and the mapping is correct, then the cause is often inside the application. JSP files may reference missing beans, old classes, invalid EL expressions, or database resources that are unavailable.
Common application-level causes include:
- NullPointerException in a servlet or JSP
- database connection failure
- missing configuration file
- incorrect file permissions for uploads or temp files
- classpath conflict between bundled libraries and server libraries
Check the logs first
Logs are the most reliable way to find the cause of a broken JSP application. In hosted Java environments, the browser error is only the symptom. The logs tell you what actually failed.
Where to look
Depending on your hosting setup, you may have access to:
- Tomcat stdout and stderr logs
- application-specific logs
- Apache error logs
- control panel service logs
- startup logs for the Java service
In Plesk-based Java hosting, the service control and log access area is usually the best place to start. If you are using a private app server, also check any log files configured for that specific instance.
What to search for in the logs
Look for the first error before the long stack trace. The first meaningful exception often reveals the real root cause. Search for:
SEVEREExceptionCaused byClassNotFoundExceptionNoClassDefFoundErrorFileNotFoundExceptionConnection refusedOutOfMemoryError
If the application fails immediately at startup, focus on startup logs. If it only fails on one page, inspect the request-time stack trace for that page.
Common causes of broken JSP apps and how to confirm them
1. Wrong context path or deployment location
A JSP app may be deployed successfully but still appear broken if the context path changed. This is common after redeploying a WAR file or moving the app into a custom application server directory.
How to confirm:
- check the deployed application name in the control panel
- compare the requested URL with the actual context path
- verify whether the app is supposed to open at the domain root or a subpath
If the app opens only when using a specific path, update links, redirects, and any reverse proxy rules so they match the current deployment.
2. Java version mismatch
Some JSP applications require a specific Java version. If the app was developed for an older runtime and the server now uses a newer one, or the other way around, you may see startup failures or runtime exceptions.
How to confirm:
- check the Java version selected for the app server
- compare it with the app’s documented requirement
- inspect the logs for unsupported class version or API errors
With a hosting platform that allows selecting a Java version for the app server, this is one of the fastest issues to rule out.
3. Missing or broken libraries
A JSP app often depends on third-party JAR files. If one dependency is missing, duplicated, or the wrong version, the app may fail only at runtime.
Common symptoms include:
ClassNotFoundExceptionNoClassDefFoundError- page-specific 500 errors
- failure after a recent deploy
Check whether the app includes all required files in WEB-INF/lib and whether you accidentally uploaded an incomplete WAR archive. If the application worked before and failed after a redeploy, compare the current package with the previous working version.
4. JSP compilation errors
JSP pages are compiled on demand. A syntax issue, missing import, or invalid expression may not appear until the page is first requested.
Examples include:
- missing semicolon in embedded Java code
- invalid tag library reference
- bad expression language syntax
- references to renamed classes or methods
The logs usually show the exact JSP file and line number. If the error points to a JSP, open that page first and inspect the line highlighted in the stack trace.
5. Database connection problems
Many JSP applications depend on a database. If the database is unavailable, the app may still load the home page but fail on login, search, or data-driven pages.
Check for:
- wrong database host, username, or password
- database service unavailable
- connection pool exhaustion
- firewall or network restrictions
- SSL or driver mismatch
In the logs, this often appears as a connection timeout, authentication failure, or SQL exception. If only data pages fail, the web layer is probably fine and the database layer needs attention.
6. File permissions or upload path issues
JSP apps that write files, generate exports, or process uploads may fail if the target directory is not writable. The same is true for temporary directories used by the Java runtime.
Confirm:
- the upload directory exists
- the Java process can write to the expected path
- temporary directories are available and not full
- file permissions match the hosting account’s requirements
Permission issues often show up as AccessDeniedException, FileNotFoundException, or application-specific errors when saving data.
7. Resource limits or memory pressure
A small or medium JSP application can still break if it runs out of memory or hits process limits. In managed hosting, the app server may be intentionally constrained to keep the service stable for the account.
Signs of resource trouble include:
- slow response before failure
- service restarts after traffic spikes
OutOfMemoryError- GC-related slowdown
- pages timing out under load
If you suspect memory pressure, review the application size, number of background threads, image processing jobs, and any caching layers inside the app. Keep in mind that a private JVM in shared hosting is suitable for small and medium apps, not heavy cluster-style production architectures.
Practical troubleshooting workflow
Step 1: Reproduce the error consistently
Open the affected page in a clean browser session and note the exact URL, time, and error message. If possible, test from another device or network. Consistent reproduction helps correlate the browser error with a specific log entry.
Step 2: Verify service status in the control panel
Check the app server status, current Java version, and recent changes. If the service was restarted recently, inspect startup output before anything else.
Step 3: Confirm deployment and context path
Make sure the app is deployed where you think it is. If you use a WAR file or custom app server setup, confirm the active application directory and the expected public URL.
Step 4: Review Apache and Tomcat logs
Match the time of the browser error with the logs. If Apache logs show a routing problem, fix the proxy or mapping. If Tomcat logs show a stack trace, focus on the JSP or servlet code. If the logs show a startup crash, inspect the application initialization path.
Step 5: Test with a minimal page
Create or deploy a simple test JSP that only outputs a small line of text, such as a hello page. If the test JSP works but the main app fails, the hosting stack is healthy and the problem is in the application code or configuration.
Step 6: Roll back the latest change
If the application stopped working after a deploy, revert the latest change first. This includes updated libraries, configuration files, servlet mappings, and JSP edits. A recent change is often the fastest path to the root cause.
Using My App Server effectively for diagnosis
In a hosting environment that provides Java hosting through a Plesk extension such as My App Server, you have a practical advantage: you can manage the app server, choose a Java version, and isolate the application inside its own JVM within the hosting account. That makes troubleshooting easier than sharing one generic runtime across multiple apps.
To diagnose a broken JSP application, use these controls in a structured way:
- confirm the app server is running
- restart the service only after checking the current logs
- verify the selected Java version
- check whether the deployed app is the correct one
- use a clean redeploy if the package may be incomplete
If the application was configured manually, verify any custom server settings carefully. A small typo in a context file, environment variable, or startup parameter can prevent the whole app from loading.
How to narrow down a 404 error
A 404 usually means the request never reached the page or the server could not find the mapped resource. In JSP hosting, this can happen even when the app is installed correctly.
Check these points:
- is the JSP file actually deployed inside the application package?
- is the context path correct?
- is the request being forwarded to Tomcat?
- did a rewrite rule send the request to the wrong location?
- was the page renamed, moved, or removed in the latest build?
If a direct JSP URL returns 404 but the app root loads, the page may need a controller mapping, a different path, or a front controller route rather than direct file access.
How to narrow down a 500 error
A 500 error means the request reached the server but something failed during processing. This is usually where the logs become essential.
Common 500 causes in JSP apps include:
- uncaught Java exception
- missing request parameter
- database failure
- template or JSP compilation issue
- library conflict
If the error occurs only on one action, test the same page with a different user, different input, or a simplified request. If the page works with empty data but fails with specific content, the issue may be validation-related rather than server-related.
When to redeploy and when not to
A clean redeploy is useful when the app package may be corrupted, incomplete, or inconsistent. However, redeploying repeatedly without checking logs can hide the real problem.
Redeploy if:
- the WAR upload may have failed
- libraries are missing
- the deployment directory is out of sync
- the app worked before a recent upload
Do not rely on redeploy alone if:
- the logs show a Java syntax or runtime error
- the JVM version is incompatible
- the database is down
- the app fails during initialization every time
Frequently asked questions
Why does my JSP app show 404 even though the service is running?
The service may be running, but the app may not be deployed at the URL you are requesting. Check the context path, proxy mapping, and deployment location. A 404 is often a routing or path issue rather than a service failure.
Why do I get 500 errors only on some JSP pages?
This usually means the app starts correctly, but the failing pages depend on data, a missing class, a database query, or a JSP-specific runtime error. Review the stack trace for the exact page and line number.
What should I check first after a JSP application stops working?
Start with the app server status, then check the logs, then confirm the deployment path. That sequence gives the fastest answer in most hosted Tomcat setups.
Can a Java version change break a working JSP app?
Yes. If the app was built for a different Java version, class loading or runtime compatibility errors can appear after switching the Java runtime. Always compare the app’s requirement with the selected server version.
How do I know if the issue is in Apache or Tomcat?
If static files work but JSP requests fail, check the routing to Tomcat. If the request reaches Tomcat and returns a stack trace or 500 error, the problem is likely in the Java application itself.
Should I contact hosting support if I cannot see the logs?
Yes. If you cannot access the relevant service logs or the app server will not start, support can help confirm whether the issue is configuration, deployment, or a runtime failure. Include the exact URL, time of error, and any visible message from the browser.
Conclusion
To find the cause of a broken JSP application, work from the outside in: verify the service status, check the URL and context path, review the logs, and then isolate whether the failure is in Apache, Tomcat, or the application code. In a managed Java hosting environment with Plesk and a private app server, this process is usually straightforward because you can inspect service control, choose the Java version, and redeploy the application without changing the whole hosting account.
Most issues come down to one of a few common causes: wrong routing, missing libraries, Java version mismatch, database failure, or a deployment problem. If you follow the checks in this guide in order, you can usually identify the root cause quickly and decide whether the fix is a configuration change, a redeploy, or a code correction.