When a JSP application stops behaving as expected, the fastest way to find the cause is usually in the application logs. In a managed hosting environment with Plesk and a private JVM or Apache Tomcat instance, logs can tell you whether the issue is a deployment problem, a Java error, a missing class, a configuration mismatch, or a runtime exception happening inside your JSP pages or servlets.
If you are using a JSP hosting setup such as My App Server, the log files are especially important because they help you understand what happened inside your Tomcat-based application without needing direct server access. This guide explains how to read JSP application logs, where to look in Plesk, what common errors mean, and how to narrow down problems quickly in a UK hosting context.
Where JSP application logs are usually found
The exact path depends on how your application server is configured, but in a typical hosting control panel environment you will usually see logs in one or more of the following places:
- Tomcat logs for the application server itself
- Application logs written by your Java app or framework
- Plesk domain logs for web requests and deployment-related events
- System or service logs for startup and shutdown messages
In a My App Server setup, your JSP application may run in its own private JVM or dedicated Tomcat instance under the hosting account. That means logs are often separated by service, which makes troubleshooting easier. You can usually inspect them from the Plesk file manager, through the application server settings, or by downloading them locally for review.
Common log locations to check first
- catalina.out or equivalent Tomcat console log
- localhost.log for local server events
- stderr/stdout logs if the service redirects output there
- application-specific log files if your app uses Log4j, Logback, JUL, or a similar logging framework
- web server access and error logs if the issue is around request handling or proxying
What to look for in JSP logs
When something goes wrong, do not read the log from top to bottom at random. Start with the time of the failure and search for the exact request, exception, or restart event. Most log files include timestamps, thread names, log levels, and stack traces. These details help you connect the error to a specific user action or deploy.
Important log patterns
- ERROR or SEVERE entries: usually indicate a real failure
- Exception lines: show the Java error type
- Caused by: often reveals the underlying root cause
- Stack trace: shows where in the code the error happened
- OutOfMemoryError: indicates the JVM ran out of heap or native memory
- ClassNotFoundException or NoClassDefFoundError: missing or incompatible dependency
- FileNotFoundException: missing file, config, upload target, or path issue
- BindException: port already in use or service startup conflict
For JSP applications, one of the most common causes of failure is a compilation or runtime exception inside a JSP file. Since JSP pages are translated into servlet code, the error message may reference a generated Java class, line number, or the original JSP filename. Pay attention to the mapping between the generated class and your JSP page.
How to read a JSP stack trace
A Java stack trace is the most useful part of a failure log. It shows the path taken by the code before the exception was thrown. The top line usually tells you the error type, while the lower lines show the call chain that led to the failure.
Example of how to interpret it
If you see something like a NullPointerException, the real question is not only what exception occurred, but where the null value came from. Look for:
- the first line that mentions your application package
- the JSP file name or servlet class
- the line number in the source or generated code
- any nested Caused by section
For example, a stack trace may show a database call failing first, followed by a template rendering error in a JSP page. In that case the JSP page is the place where the failure surfaced, but the root cause may be in the database connection, query, or datasource configuration.
What the main exception types often mean
- NullPointerException — a variable or object was not initialized
- SQLException — database access failed or returned invalid data
- ServletException — a servlet or JSP processing error occurred
- IOException — file, network, or stream problem
- ClassCastException — incompatible types in code or libraries
- IllegalStateException — the application was used in the wrong state
Step-by-step: diagnose a JSP issue from logs in Plesk
Use this practical process when your JSP app is not loading correctly or is showing a 500 error.
1. Confirm the time of the failure
Start by identifying when the problem began. Was it after a deployment, a service restart, a configuration change, or a new data import? Matching the time helps you avoid reading unrelated log entries.
2. Check whether the service is running
In Plesk, verify the status of the Java service or Tomcat instance. In a My App Server environment, service control is typically handled through the hosting panel. If the service is stopped, restarting it may immediately show startup errors in the logs.
3. Search for the error timestamp
Open the relevant log and search for the time when the issue happened. Look a few minutes before and after that point. Often the real cause appears slightly earlier than the visible failure.
4. Find the first error, not just the last one
The last exception in the log may be only a symptom. The first meaningful error is often the most important. For example, a database connection failure may trigger a later JSP rendering error. Fix the root problem first.
5. Read the complete stack trace
Do not stop at the top line. Scroll through the full trace and find any Caused by sections. These can point to missing files, classpath conflicts, invalid configuration values, or upstream service failures.
6. Compare with recent changes
If the logs started failing after a new WAR upload or JSP update, compare the log output with the last deployment. A missing library, bad encoding setting, or changed context path is often the reason.
7. Check the application server logs too
Sometimes the web request log looks clean, while Tomcat logs show the actual failure. In a hosting setup with a private JVM, server logs are critical for understanding startup problems, memory pressure, and deployment errors.
Common JSP log problems and what they usually mean
HTTP 500 with no visible page output
A generic server error usually means the application threw an exception during request processing. Check the JSP stack trace, the server log, and any custom app log. If the page renders partially before failing, the issue may be caused by a tag library, scriptlet, controller logic, or backend call.
JSP compilation error
If the log mentions JSP translation or compilation, the page may contain a syntax problem, a bad tag, a missing import, or a typo in an expression. Common examples include:
- unclosed tags or quotes
- invalid Java code inside a scriptlet
- missing JSTL or custom tag library references
- incorrect page encoding
ClassNotFoundException or NoClassDefFoundError
This usually points to a missing JAR, a dependency mismatch, or an incorrect deployment layout. In Tomcat-based hosting, make sure the required libraries are in the right location and that the application is using the expected Java version.
Database connection errors
If your JSP app uses a datasource, the log may show connection refused, timeout, authentication failure, or driver issues. Check:
- database hostname and port
- username and password
- JDBC driver version
- connection pool settings
- network access between the app and database
OutOfMemoryError
This error means the JVM has run out of memory. In a private JVM setup, memory settings may need adjustment, or the application may have a leak or unusually large workload. Review heap usage, thread count, and any recent increase in uploads, caching, or session storage.
Permission denied or file access errors
These logs often indicate that the app cannot write to a directory, read a config file, or access uploaded content. Check file ownership, directory permissions, and whether the application is trying to use an absolute path that does not exist in the hosting account.
Reading logs after a restart
Service restarts are common in managed hosting, especially after deploys or configuration changes. After a restart, review the logs in this order:
- service startup messages
- deployment scan or application deploy messages
- JSP compilation output
- runtime errors after the first request
If the app starts successfully but fails only when a page is loaded, the problem is likely in request handling or backend logic. If the service fails during startup, focus on configuration, port binding, Java version compatibility, or missing libraries.
How Java version and Tomcat version affect log messages
In a hosting platform that offers different Java and Tomcat versions, the log output can change depending on the runtime selected for the app. A JSP application that works on one Java version may fail on another because of deprecated APIs, changed TLS defaults, or library incompatibilities.
When reviewing logs, note the Java runtime version and the Apache Tomcat version used by your app. If a failure began after switching versions, check whether the application depends on older libraries or language features.
Version-related signs in logs
- unsupported major.minor version
- class file version mismatch
- deprecated API warnings
- module or reflection access warnings
- startup errors after a Java upgrade
Useful log-reading habits for JSP hosting
Reading logs becomes much faster when you develop a routine. In a hosted JSP environment, the goal is not only to see that an error happened, but to understand how the application behaved before and after it failed.
- Always note the exact timestamp of the issue
- Review both application and server logs
- Search for the first error before the final failure
- Check recent changes in code, config, or deployed files
- Keep your own deployment notes so log entries are easier to match
If your application uses a logging framework, set clear log levels. For day-to-day troubleshooting, INFO helps you understand normal flow, while WARN and ERROR help you isolate failures. Avoid logging sensitive information such as passwords, session tokens, or personal data.
Best practices for JSP log files in managed hosting
On a shared or managed hosting account, logs can grow quickly. Good log hygiene makes diagnosis easier and helps you stay within hosting limits.
- Rotate large log files regularly
- Remove old debug output once the issue is fixed
- Use clear log prefixes for your application name or module
- Separate application logs from access logs if possible
- Archive log snapshots before and after major releases
If your hosting setup includes a private Tomcat instance, log rotation and service management may be handled through the control panel or the app server settings. This is useful for JSP hosting because it keeps operational logs separated from your codebase and makes support analysis easier when you need help from the hosting team.
When to contact support
Some issues can be solved directly from the logs, but others need hosting-side review. Contact support if you see repeated service crashes, startup failures that you cannot explain, or errors related to the Tomcat service itself rather than the application code.
When you ask for help, include:
- the exact time of the failure
- the relevant log excerpt
- the JSP page or URL that failed
- recent changes you made
- the Java and Tomcat version in use
Providing a short, accurate log snippet is usually more helpful than sending a whole file. The best excerpt is the section that starts a few lines before the error and includes the full stack trace.
FAQ
Why does my JSP page show a 500 error but the browser does not explain more?
A browser usually shows only the HTTP status, not the real server-side cause. The detailed reason is normally in the JSP, Tomcat, or application log. Check the timestamp and search for the exception that matches your request.
What is the most important line in a Java stack trace?
Usually the first exception line and the first Caused by section are the most useful. They often reveal the actual root cause, while later lines show the impact on the rest of the application.
How do I know whether the problem is in JSP code or server configuration?
If the error appears only on one page, it is often a JSP or application logic issue. If the service fails at startup, the problem is more likely configuration, Java version, missing libraries, or a Tomcat-level issue.
Can I use logs to check if a deployment succeeded?
Yes. After uploading a WAR or changing JSP files, the logs should show deployment or reload activity. If the application starts but pages fail later, the deployment may have succeeded but the runtime code still contains an error.
What should I do if the log is full of repeated errors?
Focus on the first error in the sequence and the event that triggered repetition. Repeated messages often come from a loop, a retry mechanism, or a service that keeps restarting after the same failure.
Conclusion
Reading JSP application logs is one of the most effective ways to diagnose problems in a managed hosting environment. Whether you are dealing with a JSP compilation error, a missing library, a database failure, or a Tomcat startup issue, the log file usually contains the clues you need.
In a Plesk-based hosting platform with My App Server, log review is especially practical because you can inspect the Java runtime, the Tomcat service, and the application output from one control panel workflow. Start with the failure time, find the first real error, read the full stack trace, and compare the result with your recent changes. With that approach, most JSP issues become much easier to identify and fix.