When a JSP application fails to start, the fastest way to find the cause is usually in the logs. In a hosted Java environment, logs can show whether the problem comes from Tomcat, the JVM, your web application, missing files, configuration errors, permission issues, or a deployment that did not complete correctly.
If you use a managed hosting platform with Plesk and a private JVM or Apache Tomcat service, log review is one of the most practical troubleshooting steps you can take before changing settings or redeploying the application. In many cases, the exact error appears a few lines before the service stops, the deployment fails, or the JSP app returns a blank page or HTTP 500 response.
Why logs matter when a JSP app will not start
JSP hosting problems often look similar from the outside. The application may not load, Tomcat may stop during startup, or the site may respond with an error page. Logs help you separate the symptom from the real cause.
Common startup issues that logs can reveal include:
- Java version mismatch between the app and the selected runtime
- Broken or incomplete WAR deployment
- Missing libraries in
WEB-INF/lib - Servlet, filter, or listener initialization errors
- Port binding conflicts
- Invalid context configuration
- File permission problems inside the hosting account
- OutOfMemoryError or memory pressure during startup
- Database connection failures caused by bad credentials or unavailable services
For hosted Tomcat and JSP applications, logs are especially useful because the platform usually keeps the application isolated inside its own service or private JVM. That means the startup problem is often visible in the application or service log without needing access to the entire server.
Where to check logs in a Plesk-based Java hosting setup
In a typical Plesk environment with My App Server, log access may be available in several places depending on how the Java app is installed and managed. You may have access to:
- Tomcat or application server service logs
- Application deployment logs
- Web server logs if Apache is proxying requests to the app
- JVM output logs, including
stdoutandstderr - System or service control logs related to the Java process
If you are using the My App Server extension, start with the service control area in Plesk and then open the most relevant log file for the selected app server instance. If the application starts but does not respond correctly, also check the Apache logs, because the issue may be in the proxy layer rather than Tomcat itself.
Most useful log files for JSP startup troubleshooting
- Tomcat catalina log — often the main source for startup failures
- Application-specific logs — helpful if the app writes its own startup output
- Apache error log — useful when requests reach Apache but not the app
- JVM output log — may show class loading, memory, or JVM argument issues
- Deployment log — useful when the WAR upload or unpack process fails
How to read startup logs effectively
Many users open a log file and search for the first obvious error message. That is a good start, but startup problems often begin earlier than the visible failure. The key is to read the log in context.
Step 1: Find the startup window
Look for the time when the service was started or restarted. In Tomcat logs, this is usually near messages such as:
- Starting Servlet Engine
- Server startup in ... ms
- Deploying web application archive
- Initializing Spring embedded WebApplicationContext
If the service stops before a successful startup message appears, the problem is likely during initialization. If startup completes but the app still fails, the issue may be inside the application context, not the server itself.
Step 2: Look for the first real error
Do not stop at the last line of the log. The last line often reports the final symptom, while the original cause appears earlier. Search for:
ERRORSEVEREExceptionCaused byBindExceptionClassNotFoundExceptionNoClassDefFoundErrorOutOfMemoryError
In Java stack traces, the first exception is not always the root cause. Follow the chain down to the bottom-most Caused by line. That line often identifies the actual reason the JSP app could not start.
Step 3: Match the error with the deployment phase
Different errors usually happen at different points in the startup process:
- Before deployment — service, JVM, or configuration issue
- During unpacking — WAR structure, permissions, or disk space problem
- During webapp initialization — missing class, broken servlet config, bad framework setup
- After startup — database, routing, or runtime request problem
Understanding the phase helps you avoid changing the wrong setting.
Common log patterns and what they mean
ClassNotFoundException or NoClassDefFoundError
These errors usually mean the app expects a library that is not present in the deployed package or not compatible with the selected Java/Tomcat version. In JSP hosting, this often happens when a WAR file was built for a different runtime or when a dependency was excluded from WEB-INF/lib.
Check whether the application was deployed with all required JAR files and confirm that the selected Java version matches the application requirements.
Servlet or JSP compilation errors
If a JSP file does not compile, the logs may show a syntax problem, tag library issue, or missing class referenced by the page. You may see messages related to:
- JSP compiler errors
- Tag library not found
- Compilation failed
- Invalid directive or expression
This is often caused by a template or code change introduced during deployment.
BindException or port already in use
If Tomcat cannot bind to a port, another process may already be using it, or the application server may have been configured with a conflicting connector. On shared hosting with a private JVM, this can happen when the service is restarted with a bad custom configuration.
Check the connector configuration and make sure the selected ports are allowed by the hosting platform.
Permission denied or access errors
If the logs show file access failures, the app may not be able to read configuration files, write to a temp directory, or open uploaded resources. This is common when the app expects write access outside the allowed hosting paths.
Review:
- Application file ownership
- Directory permissions
- Writable temp and log directories
- Paths used in
context.xmlor application settings
OutOfMemoryError during startup
A memory-related failure may appear if the JVM heap is too small for the application’s startup requirements or if the app loads too many resources at initialization. In a managed hosting environment, memory limits are important because the app server runs within account-level service constraints.
If you see memory exhaustion in the log, review the JVM settings and the application’s startup workload. Reducing unnecessary initialization tasks can sometimes help more than simply increasing memory.
Database connection failures
Many JSP and servlet applications connect to a database during startup. If the database is unavailable or credentials are wrong, the app may fail before serving traffic.
Typical log messages include:
- Connection refused
- Access denied for user
- Timeout while connecting
- JDBC driver not found
Verify the datasource settings, JDBC driver availability, host name, port, username, password, and database permissions.
Practical troubleshooting workflow
Use this process when a JSP application does not start properly on a hosted Tomcat setup.
1. Restart the service and capture fresh logs
After confirming that the app is not running, restart the Tomcat or Java service from the control panel. Fresh logs are easier to read than old ones because they show only the current startup attempt.
If your hosting platform provides service control in Plesk, use that rather than manually editing files first. A clean restart can also show whether the issue is repeatable.
2. Check the first failure point
Open the most relevant log and search for the earliest ERROR or SEVERE entry in the startup sequence. Read several lines before and after it. Often the root cause is a configuration line or class reference that appears just before the failure.
3. Verify Java version and server version
Some JSP applications need a specific Java version or a particular Tomcat generation. If the app was built against a newer or older runtime, it may fail during class loading or JSP compilation.
In My App Server, choose the Java/Tomcat version that matches the application requirements as closely as possible.
4. Inspect the deployed package
Confirm that the WAR file contains the expected structure:
WEB-INF/WEB-INF/web.xmlif the application uses itWEB-INF/classes/WEB-INF/lib/
If deployment logs show an unpacking or validation problem, re-upload the archive and redeploy it cleanly.
5. Review external dependencies
Startup problems often come from missing services outside the application itself. Check whether the app needs:
- Database access
- SMTP settings
- Environment variables
- Configuration files in a specific path
- Third-party JARs shipped with the app
If the log shows a failure during an external call, test that dependency separately before changing the JSP code.
6. Compare successful and failed deployments
If the application used to start and now does not, compare the current logs with the last known good deployment. Changes in error messages often point to a recent code update, configuration edit, or runtime switch.
How Apache logs can help when Tomcat looks fine
In some hosting setups, Apache sits in front of Tomcat and handles incoming HTTP requests. If Tomcat starts successfully but the site still does not work, Apache logs may show routing, proxy, or rewrite issues.
Check the Apache error log if you see:
- 502 or 503 responses
- Proxy connection failures
- Bad gateway messages
- Rewrite rule loops
- Incorrect backend target ports
This is especially important when the app server is managed through a control panel and the request path depends on a connector or proxy configuration.
What to collect before contacting support
If you cannot fix the issue yourself, gather the most useful details before opening a support ticket. This helps speed up investigation on a managed hosting platform.
- Time of the failed startup attempt
- Exact application name or domain
- Java version and Tomcat version in use
- The last 50 to 100 lines of the relevant log
- The full exception stack trace if available
- Recent changes made before the failure
- Whether the issue happens after restart, redeploy, or both
If the log contains sensitive data such as passwords or tokens, redact those values before sharing the file.
Best practices to make JSP startup troubleshooting easier
- Keep application logs enabled and rotated
- Use consistent names for deployments and versions
- Document which Java version the app requires
- Store configuration outside the web root when possible
- Avoid manual edits on live deployments without a rollback plan
- Test new WAR uploads in a controlled way before replacing the active version
- Review startup logs after each major code or framework change
In a hosted environment with a private JVM, these habits save time because they make each startup attempt easier to compare and isolate.
FAQ
Why does my JSP app stop during startup with no clear message?
The root cause may appear earlier in the log than the final stop message. Search for the first SEVERE, ERROR, or Caused by entry and read the full stack trace.
Which log should I check first for Tomcat startup problems?
Start with the Tomcat catalina log or the main service log for your My App Server instance. If the app starts but web requests fail, also check the Apache error log.
How do I know if the issue is in my JSP code or the hosting environment?
If the log shows JSP compilation errors, missing classes, or application initialization failures, the issue is usually in the app or its package. If you see port binding, service startup, or permission issues, the hosting configuration or runtime setup may be involved.
Can a wrong Java version prevent JSP startup?
Yes. A Java application built for one runtime may fail to start on another, especially if it uses newer language features, incompatible libraries, or deprecated APIs.
What should I do if the log shows a database connection failure?
Check the database host, port, username, password, schema permissions, and JDBC driver. If the database is external, confirm that it is reachable from the hosting environment.
Why does the app start sometimes but fail after a redeploy?
This often points to incomplete deployment, stale files, conflicting classes, or an initialization step that depends on a resource not present after the new upload.
Conclusion
Logs are the most reliable way to troubleshoot a JSP startup problem on a hosting platform. They show whether the failure is caused by the application package, the selected Java or Tomcat version, a permission issue, a database dependency, or a service configuration problem. In a Plesk-managed Java hosting setup with My App Server, checking the right log file and reading the full startup sequence can quickly narrow the issue from a vague “the app will not start” problem to a specific fix.
When you combine log review with the service controls, version selection, and deployment tools available in your hosting panel, troubleshooting becomes much faster and more predictable. That is usually the best path for JSP hosting, servlet hosting, and private JVM environments that need practical day-to-day administration rather than complex enterprise tooling.