How to find the cause of a broken JSP application

When a JSP application stops working, the cause is usually one of a few common issues: an application error, a deployment problem, a Tomcat or JVM startup failure, a missing library, or a web server rule that blocks access before the request reaches your app. In a hosting environment, the fastest way to diagnose the problem is to check the public error, review the application and server logs, and confirm that the Java service, Tomcat configuration, and deployed files are all consistent.

This guide explains how to find the cause of a broken JSP application in a hosted Java environment such as Plesk with My App Server, where you can run your own Apache Tomcat instance and manage the Java version, service, and deployment from the control panel.

What “broken” usually means for a JSP application

A JSP application can fail in different ways, and the visible symptom helps narrow down the root cause:

404 Not Found - the application, context path, or specific page is not reachable.
500 Internal Server Error - the request reaches the app, but the app throws an exception.
Blank page or partial output - JSP compilation or template rendering fails, or the app exits early.
Application deploys but does not start - Tomcat or the JVM has a startup issue.
Static assets load, but dynamic pages fail - the deployment is partially correct, but JSP, servlet, or backend logic is broken.

In hosting environments, the problem is often not the JSP file itself. It may be related to a wrong WAR structure, an incorrect web.xml, a Java version mismatch, a missing library, a permissions issue, or a service problem inside Tomcat.

Step 1: Identify the exact error and where it appears

Start by checking what the browser shows and when the error occurs:

404 before the app loads usually means routing, context path, document root, reverse proxy, or deployment path problems.
500 after the app loads usually means application code, JSP syntax, dependency, or runtime errors.
Error only on one page usually points to a JSP page, tag library, or controller issue.
Error after deployment or restart usually means Tomcat, JVM, or startup configuration problems.

Test more than one URL:

The root of the app, for example /
A known JSP page, for example /index.jsp
A servlet or mapped endpoint, if your app has one
A static file, such as an image or CSS file, to see whether only dynamic processing fails

If static files work but JSP fails, the application container is likely running, but the JSP compilation or application logic is failing.

Step 2: Check the application logs first

For a broken JSP application, logs are usually the most useful source of information. Look for the following:

JSP compilation errors
Java stack traces
ClassNotFoundException or NoClassDefFoundError
Servlet initialization failures
Database connection errors
Permission denied messages
OutOfMemoryError or startup crashes

Typical log locations in a hosted Tomcat environment may include the Tomcat logs directory, application-specific logs, or the service logs accessible from the control panel. In Plesk-based Java hosting with My App Server, the service and application logs are often the first place to check after a failed deployment or a 500 error.

When reading logs, look for the earliest error in the sequence. The first error is often the real cause; the later errors are often only the result.

Common log messages and what they usually mean

HTTP Status 404 - wrong path, missing context, app not deployed, or incorrect rewrite/routing.
HTTP Status 500 - runtime exception in code or JSP.
JasperException - JSP compilation or rendering problem.
java.lang.NoSuchMethodError - incompatible library versions.
java.lang.ClassNotFoundException - missing JAR or classpath issue.
SEVERE: Error starting child - Tomcat failed to start the web application.
Address already in use - port conflict, usually when a custom Java service starts incorrectly.

Step 3: Verify that the Java service and Tomcat are running

If you use a hosting platform with your own Tomcat instance, confirm that the service is actually up. In My App Server, the service can be controlled from the control panel, so a broken app may simply be a stopped or failed service rather than a code problem.

Check the following:

The Tomcat service is started
The correct Java version is selected
The service status is healthy after restart
No recent configuration change caused the service to fail

If the service will not start, the problem may be in the JVM version, startup parameters, memory limits, or a broken deployment that prevents Tomcat from completing initialization.

Things to confirm in the control panel

Whether the app server is enabled for the subscription or domain
Whether the selected Java runtime matches the application requirements
Whether the deployed version is the one currently active
Whether the application root and context path are correct
Whether custom start parameters were changed recently

Step 4: Check for a deployment problem

Many broken JSP apps are caused by an incomplete or invalid deployment rather than a code bug. This is especially common after uploading a WAR file or updating files manually.

Check the following deployment points:

The WAR file was uploaded completely
The application was unpacked correctly
The expected folder structure exists
JSP files are in the correct location
Libraries are present under WEB-INF/lib
Compiled classes are under WEB-INF/classes
The WEB-INF/web.xml file is valid, if used

A broken deploy can produce a 404 if the app never loaded, or a 500 if the app is deployed but fails during initialization.

If you use a private JVM and Tomcat through My App Server, redeploy the application cleanly rather than copying changed files over an already running deployment, especially if the app has changed libraries or configuration files.

Step 5: Review JSP syntax and compilation errors

JSP files are compiled into Java code by Tomcat. A small syntax issue can break the whole page or the entire application.

Common JSP problems include:

Unclosed scriptlet tags
Broken expressions or tag syntax
Missing tag library declarations
Invalid Java statements inside JSP scriptlets
References to classes that are not available in the runtime
Encoding issues in the source file

Examples of errors that often appear in logs:

Unable to compile class for JSP
ParseException
JSP file not found
IllegalStateException during rendering

If only one JSP page fails, isolate that page and check whether it uses a custom tag library, includes another file, or depends on an object that is sometimes null. A clean redeploy after fixing the page can help clear stale compiled JSP classes.

Step 6: Check Java version compatibility

A JSP application may work on one Java version and fail on another. This is a common issue in hosted Java environments where the runtime can be selected from several available versions.

Look for these compatibility problems:

The app was built for an older Java version but runs on a newer one
The app needs a newer Java version than the one selected
A dependency was compiled for a different Java release
The code uses removed or deprecated APIs

In My App Server, one practical advantage is that you can choose from several ready-to-install Java/Tomcat versions, or upload and configure a custom version when needed. If your application broke after a runtime change, test it with the Java version it was built for.

Signs of a Java version mismatch

UnsupportedClassVersionError
NoSuchMethodError after dependency updates
IllegalAccessError
App starts but certain features fail immediately

Step 7: Inspect dependencies and libraries

JSP applications often depend on external JAR files. If one is missing, duplicated, or incompatible, the app may fail at startup or when a page is called.

Check for:

Missing JAR files in WEB-INF/lib
Duplicate libraries with different versions
Conflicts between bundled and server-provided libraries
Libraries that are valid on development but not on the hosted runtime

Dependency problems are often visible in the logs as class loading errors. If the app worked before and stopped after an update, compare the previous and current library set carefully.

For hosted JSP and servlet applications, keeping all app-specific libraries inside the application package is usually safer than relying on unclear shared dependencies.

Step 8: Check permissions, ownership, and file paths

File permission issues can make an application appear broken even when the code is fine. Tomcat must be able to read deployed files, write temporary files, and create cache or work directories where needed.

Verify the following:

The application files are readable by the service account
The JSP work directory can be created and written to
Uploads and temporary files are stored in writable locations
Absolute file paths in the app are valid on the hosting account

Problems with file paths are especially common when an application was moved from local development to hosting. A path that worked on a developer machine may not exist in the server environment.

Typical file-related causes

Using a local Windows path in production code
Hardcoded absolute paths that do not match the hosting account
Missing write permission for uploaded content
Temporary directory cleanup errors

Step 9: Test whether the problem is caused by a backend dependency

Sometimes the JSP page is only the visible failure point. The real cause is a database, API, or external service connection problem. When the backend is unavailable, the page may show 500 errors or render incomplete content.

Check for:

Database connection failures
Invalid credentials in configuration files
Timeouts when connecting to APIs
DNS or network resolution problems
Expired certificates or trust issues

If the page fails only when data should be loaded, test the backend connection separately. A broken JDBC connection, for example, can stop a JSP page even though Tomcat itself is healthy.

Step 10: Isolate the failure with a simple test page

If the cause is still unclear, create or deploy a minimal JSP file to test the runtime independently of your application logic. A simple page that prints a static message can show whether JSP processing itself works.

If the test page works:

Tomcat is running
JSP compilation works
The issue is inside your application code or configuration

If the test page also fails:

The issue is with the runtime, deployment, permissions, or service configuration
You should focus on Tomcat logs and control panel service status

This kind of isolation is one of the most efficient troubleshooting methods in shared Java hosting because it separates app-level errors from platform-level problems.

Common causes by symptom

When you get a 404

Wrong URL or context path
Application not deployed
Deployment folder name does not match the URL
Tomcat service not running
Proxy or routing issue in front of the app

When you get a 500

JSP compile error
Null pointer or unhandled exception
Missing class or JAR file
Database or backend connection failure
Wrong Java version

When the app worked before and suddenly stopped

Recent code deployment introduced a regression
Runtime version changed
A dependency was updated or removed
Configuration file was edited incorrectly
Service restart exposed a startup problem

Practical troubleshooting workflow for hosted JSP applications

Use this workflow to quickly identify the cause:

Confirm whether the browser shows 404, 500, or a blank page.
Open the application and Tomcat logs.
Check whether the Java service is running in the control panel.
Verify the selected Java version.
Confirm that the deployment is complete and the context path is correct.
Look for JSP compilation, class loading, or dependency errors.
Check permissions and file paths.
Test a minimal JSP page.
Review backend connections if the app uses a database or API.
Redeploy cleanly after correcting the issue.

In a managed hosting setup, this approach saves time because it eliminates guesswork and quickly separates infrastructure issues from application bugs.

How My App Server helps with JSP troubleshooting

If your hosting plan includes My App Server, you can troubleshoot a broken JSP application more easily because you have control over the Java runtime and Tomcat service inside the hosting account.

Useful controls typically include:

Service start, stop, and restart
Java version selection
Tomcat version installation
Custom application server setup
Deploy and redeploy workflows
Access to logs for diagnosis

This is especially helpful for JSP, servlet, WAR, and small-to-medium Java applications that need a private JVM without the complexity of a separate enterprise platform.

FAQ

Why does my JSP page show 404 even though the file exists?

The file may exist on disk, but Tomcat may not be running, the app may not be deployed, or the URL may point to the wrong context path. Check the service status, deployment location, and routing.

Why do I get 500 only on JSP pages, not on static files?

This usually means the static web server part is fine, but JSP compilation, application logic, or a backend dependency is failing inside Tomcat.

How do I know if the problem is in the app or in the hosting environment?

Test a simple JSP page. If it works, the hosting platform is likely fine and the issue is inside your application. If it fails too, check logs, service status, Java version, and deployment settings.

Can a Java version change break my JSP application?

Yes. A Java upgrade or downgrade can cause class version errors, missing methods, or startup failures if the app or its libraries are not compatible.

What should I check first after a failed deployment?

Check the logs, confirm that the Tomcat service is running, verify the context path, and make sure all required JARs and configuration files were deployed correctly.

Why does my app work locally but fail on hosting?

Local and hosted environments often differ in Java version, file paths, permissions, available libraries, and servlet container configuration. Those differences are common causes of JSP failures.

Conclusion

To find the cause of a broken JSP application, always start with the visible error, then check logs, service status, deployment structure, Java version, dependencies, and file permissions. In a Plesk-based Java hosting environment with My App Server, you have the tools needed to isolate the problem quickly: a private Tomcat instance, version control for Java, and service management from the control panel.

Most JSP failures are caused by a small number of issues, and a methodical check will usually reveal the real cause without unnecessary changes. Once you identify whether the problem is routing, deployment, runtime, or application logic, you can fix it more reliably and bring the site back online faster.

How to find the cause of a broken JSP application