If your Java or JSP application is running through Plesk, the first place to check for problems is the log area connected to the domain, subscription, or application service. JSP-related issues often show up in more than one place: Apache access and error logs, Tomcat or Java service logs, and sometimes application-specific log files created by your app. Knowing where each log lives helps you identify whether the issue is coming from web routing, the JSP container, the application code, or the JVM itself.
In a managed hosting environment, this is especially useful when you are using a private JVM or Tomcat instance through Plesk, such as the My App Server setup. In that case, you usually have access to the standard Plesk website logs plus the Tomcat service logs that help with JSP compilation errors, servlet issues, startup failures, and deployment problems.
Where JSP-related logs are usually found in Plesk
Plesk does not store all logs in a single universal location. The exact path depends on how the site is configured and whether your JSP application uses Apache, Tomcat, or a separate Java service. In most cases, you should check these areas first:
- Domain logs for Apache requests, routing errors, and HTTP status codes.
- Tomcat logs for JSP compilation, servlet exceptions, startup errors, and application deployment messages.
- Java application logs created by the app itself, if logging is configured inside the application.
- Plesk service and extension logs for issues related to service control or the My App Server extension.
For JSP hosting, the most important distinction is this: Apache logs show what happened at the web server level, while Tomcat logs show what happened inside the Java runtime and JSP engine.
Check the domain logs in Plesk first
For many issues, the fastest way to begin is through the domain’s own logs in Plesk. These logs help you see whether the request reached the site, what status code was returned, and whether Apache reported a proxy or routing problem.
How to open the logs in Plesk
- Log in to your Plesk control panel.
- Go to Websites & Domains.
- Select the domain used by your JSP application.
- Open Logs or the log viewer for that domain.
- Filter by time, request path, status code, or keyword if available.
In the logs, look for:
- 404 responses for missing JSP files or incorrect application paths.
- 500 errors for server-side application failures.
- 502 or 503 errors if Tomcat is unavailable or not responding.
- Repeated redirect loops, permission errors, or proxy-related messages.
If the page loads partially or static files work but JSP pages fail, the domain logs can help confirm whether Apache is forwarding requests correctly to the Java backend.
Tomcat logs for JSP and servlet problems
When the application is using Tomcat, the most valuable logs are the Tomcat runtime logs. These logs usually contain the details you need for JSP compilation errors, classpath issues, failed deployments, missing libraries, and exceptions thrown by your Java code.
Typical Tomcat log files may include messages similar to the following categories:
- Startup and shutdown events
- Deployment of WAR files and web applications
- JSP compilation warnings or errors
- Servlet initialization errors
- Stack traces from runtime exceptions
- Memory or JVM-related warnings
If you are using a private Tomcat instance through My App Server, the Tomcat logs are often the primary source for diagnosing JSP hosting issues because they show the exact reason a page failed to compile or execute.
Common Tomcat log names to look for
The exact file names may vary, but common examples include:
- catalina.out or a similar main console log
- catalina.<date>.log
- localhost.<date>.log
- host-manager or manager logs, if applicable
- Application-specific logs stored under the Tomcat installation or application directory
On some hosting platforms, the service may be isolated per subscription, so the logs may be shown inside the Plesk file manager or in a service-specific log view rather than in a system-wide Linux path.
Using My App Server in Plesk to locate JSP logs
If your hosting plan includes My App Server, you have a practical way to manage Java hosting directly inside Plesk. This is useful because the extension provides control over the app server, Java version, and service state, which also makes log troubleshooting easier.
With My App Server, you can typically:
- Install a supported Tomcat version with a button.
- Run a private JVM under your account.
- Manage the service from Plesk without using separate server tools.
- Deploy WAR or JSP-based applications more easily.
- Switch Java versions when debugging compatibility issues.
When you are troubleshooting, the logs you need are usually linked to the app server instance created for your subscription. If a JSP page fails after deployment, check both the domain logs and the service logs from the My App Server area.
What to review inside the app server view
Depending on the setup, you may find:
- Service status information
- Start and stop actions
- App server configuration details
- Version information for Java or Tomcat
- References to log output or runtime errors
If the service fails to start, the log often shows whether the issue is caused by an invalid Java version, a port conflict, an incompatible library, or an application deployment problem.
How to identify the right log for the problem
Different JSP issues leave different traces. Choosing the right log file saves time and avoids unnecessary guessing.
If the page returns 404
Check the domain logs first. A 404 usually means one of the following:
- The JSP file path is wrong.
- The application was deployed under a different context.
- The proxy or document root is not pointing to the expected application.
If the page returns 500
A 500 error often means the request reached the application, but the JSP or servlet failed during execution. Check:
- Tomcat logs for stack traces
- Application logs for code-level errors
- Apache logs for proxy or permission issues
If you see 502 or 503 errors
These often point to a backend service problem. In a JSP hosting setup, this may mean:
- Tomcat is stopped
- The JVM is not responding
- The service port is blocked or misconfigured
- The app server failed during startup
Check the service logs and the My App Server control panel first, then confirm whether Apache can reach the Java backend.
If the JSP page compiles but behaves incorrectly
Look at both the application logs and the Tomcat logs. Some issues are not server startup problems at all. They may be caused by:
- Unexpected null values
- Database connection failures
- Missing configuration files
- Incorrect environment variables
- Class loading issues after deployment
Where the logs may physically be stored
The exact filesystem location depends on how the hosting environment is configured, but the following patterns are common in Plesk-based Java hosting:
- Domain logs under the subscription or website log area
- Tomcat logs inside the app server installation directory
- Logs under a user-owned application folder
- Service output redirected to a file such as catalina.out
If you have file access through Plesk, the file manager may help you inspect directories under your home path or application folder. If the platform hides system-level locations for security reasons, the log viewer in Plesk is usually the safest place to start.
As a rule, if the issue is about a request URL, HTTP status, or web server routing, use the domain logs. If the issue is about JSP code, Java exceptions, or deployment behavior, use the Tomcat and application logs.
Useful log patterns for JSP troubleshooting
When reading logs, search for keywords that usually point to the root cause. A few common examples include:
- SEVERE
- Exception
- StackTrace
- ClassNotFoundException
- Compilation error
- JasperException
- OutOfMemoryError
- BindException
These messages are especially useful in JSP hosting because a single compile error or missing class can prevent one page from loading while the rest of the site appears normal.
Examples of what the log may tell you
- Compilation error usually means the JSP page contains syntax problems or refers to a missing class.
- ClassNotFoundException often points to a missing JAR file or incorrect deployment structure.
- BindException may indicate that the service tried to use a port already in use.
- OutOfMemoryError can suggest that the JVM heap is too small for the workload.
How to make log checks easier in day-to-day support
In a hosted Plesk environment, it helps to keep a simple troubleshooting routine. That way, when a JSP problem appears, you can isolate it quickly.
- Confirm whether the issue is with one page or the whole application.
- Check the domain logs for the exact request and status code.
- Review the Tomcat logs for exceptions or deployment errors.
- Check the app server service status in Plesk.
- Verify that the Java version matches what the application expects.
- Look at recent changes such as new libraries, WAR uploads, or config edits.
This approach is especially effective for small and medium JSP applications hosted with a private JVM, where most issues are related to configuration, deployment, or code compatibility rather than complex infrastructure layers.
Best practices for JSP logging in Plesk
If you manage your own application logs, make sure they are easy to find and separate from the main system output. Clear logging makes support much faster and reduces downtime during troubleshooting.
- Use meaningful log names for your application.
- Include timestamps in each log entry.
- Log exceptions with full stack traces.
- Rotate logs regularly to avoid large files.
- Keep web server and application logs separate if possible.
- Record deployment time and configuration changes.
For hosted JSP applications, this is particularly helpful when several layers are involved: Apache, Tomcat, and the application code itself. A clean log structure makes it easier to identify whether the problem is in the web server, the Java service, or the JSP page.
FAQ
Where do I find JSP logs in Plesk?
Start with the domain logs in Websites & Domains, then check the Tomcat or Java service logs if the problem appears to be application-related. If you use My App Server, review the app server service area as well.
Are JSP logs the same as Apache logs?
No. Apache logs show HTTP requests and web server errors, while JSP or Tomcat logs show Java runtime activity, JSP compilation issues, and application exceptions. For a full diagnosis, you often need both.
What if my JSP application uses a private Tomcat instance?
Then the most useful logs are usually the Tomcat logs for that private instance, together with the domain logs in Plesk. This setup is common in Java hosting environments that provide a separate JVM per account.
Why do I see 500 errors but nothing obvious in the domain logs?
The problem may be inside Tomcat or the application code. Check the Tomcat logs for stack traces, class loading errors, or deployment issues. A 500 response often means the request reached the backend, but the application failed during processing.
Can I change the Java version if logs show compatibility problems?
Yes, if your hosting plan and Plesk Java setup support it. With My App Server, you may be able to choose or install supported Java/Tomcat versions and test the application against a compatible runtime.
What should I do if the logs are too large?
Filter by date, error level, or request path in Plesk if the viewer supports it. If not, focus on the time when the issue happened and search for keywords such as Exception, SEVERE, or JasperException.
Conclusion
For JSP hosting in Plesk, the key is to know which log matches which layer of the stack. Domain logs help with requests, status codes, and routing. Tomcat logs help with JSP compilation, Java exceptions, and deployment issues. If you are using a managed Java hosting setup with My App Server, you can usually control the service, choose a Java version, and troubleshoot more efficiently from within Plesk.
When in doubt, begin with the domain logs, then move to the Tomcat and application logs. That sequence usually leads you to the root cause faster and makes JSP troubleshooting much more predictable in a hosted environment.