If your JSP application is returning a 500 Internal Server Error, the issue is usually not the browser and often not even Apache itself. In JSP hosting, a 500 error normally means that the request reached your web stack, but the Java application, Tomcat instance, servlet mapping, JSP compilation, or file permissions caused the request to fail. In a Plesk-based hosting environment with My App Server, the good news is that you can usually narrow the problem down quickly by checking the app server status, the logs, the deployment path, and the Java version in use.
This guide explains how to troubleshoot a 500 error on JSP hosting in the UK, with practical steps that work well for shared hosting accounts using Apache, Tomcat, and a private JVM managed through Plesk. It is written for public-facing errors on JSP, servlet, and WAR-based applications.
What a 500 error usually means in JSP hosting
A 500 error is a generic server-side failure. In a JSP hosting context, it often appears when one of these components breaks:
- Tomcat is not running or failed to start.
- The JSP file has a syntax error or compilation problem.
- A missing class, JAR, or dependency prevents the application from loading.
- The web.xml or servlet mapping is invalid.
- Permissions prevent the JVM or Tomcat from reading application files.
- The application expects a database, environment variable, or configuration file that is not available.
- The Java version selected for the app is incompatible with the code.
- The server hit a memory, timeout, or resource limit.
With JSP hosting, the browser only shows the final symptom. The real cause is almost always in the application logs or the service status in Plesk.
Start with the quickest checks
Before changing code, confirm the service and deployment basics. These are the most common causes of a 500 error after a new deploy or a configuration change.
1. Check whether the app server is running
In a managed hosting control panel such as Plesk, open the My App Server or Java hosting area and verify that your Tomcat instance or private JVM is active. If the service is stopped, restarting it may clear a temporary startup failure. If it starts and then stops again, the issue is usually in the application configuration or startup logs.
2. Confirm the application was deployed correctly
Make sure the WAR file, exploded application directory, or JSP files were uploaded to the correct path. A partial upload can easily produce a 500 error. Check for:
- missing WEB-INF folder
- incomplete WAR archive
- wrong application root
- nested directories after upload
- old files left in the deployment folder
3. Test with a simple JSP file
Create a very small JSP page that outputs plain text only. If that page works but the main application fails, the issue is inside your app code, library set, or configuration. If even a simple JSP fails, the problem is more likely service-level, permission-related, or caused by an incorrect Java/Tomcat setup.
Check the logs first
For JSP and Tomcat hosting, logs are the fastest route to the cause. A 500 error without log review often leads to guesswork.
Where to look in Plesk
Depending on your hosting setup, review:
- Tomcat or My App Server logs
- application error logs
- Apache error logs
- deployment logs
- Java stdout and stderr output
Look for stack traces, class loading errors, file not found messages, port binding issues, permission denied errors, and JSP compilation failures. Even one line in the log can point directly to the root cause.
Common log messages and what they usually mean
- ClassNotFoundException — a required class or JAR is missing.
- NoClassDefFoundError — a dependency is present at compile time but missing at runtime.
- JasperException — JSP compilation or runtime problem.
- SEVERE: Error starting application — deployment or initialization failed.
- Permission denied — file or directory access is blocked.
- java.lang.OutOfMemoryError — the JVM needs more memory or the app is too heavy for current limits.
- HTTP Status 500 with stack trace — the error is in the application path, not the browser.
Verify Java version compatibility
One of the most common JSP hosting problems is a mismatch between the Java version used by the app server and the version your application expects. This is especially relevant when you can choose from several Java/Tomcat versions inside a control panel like My App Server.
If your application was built for an older Java release but runs on a newer one, or vice versa, you may see startup failures, JSP compilation errors, or runtime exceptions that surface as a 500 error.
What to check
- Which Java version the application was compiled against
- Which Java version is selected in the hosting panel
- Which Tomcat version is installed for the app
- Whether any third-party libraries require a specific Java runtime
If the app worked before and started failing after a Java change, switch back to the previous supported version if possible. If you uploaded a new build, confirm that the build target matches the selected runtime.
Look for JSP compilation errors
JSP pages are compiled into servlets by Tomcat. That means a syntax issue, a bad import, or a broken expression can appear to the visitor as a 500 error. This is especially common after edits to JSP pages, tag libraries, or shared includes.
Typical JSP causes
- unclosed scriptlet or expression tag
- bad Java syntax inside a JSP block
- missing tag library declaration
- incorrect include path
- incorrect character encoding
- illegal reference to a null object
How to isolate the problem
- Temporarily revert the last JSP change.
- Check whether the 500 error disappears.
- Review any included JSP fragments one by one.
- Remove custom code from the page and test with static output.
- Compare the failing page with a known working page in the same app.
If the application uses multiple JSP includes, a problem in one shared header, footer, or utility fragment can break several pages at once.
Check servlet mappings and web.xml
If the 500 error appears when a servlet route or controller path is called, the problem may be in the deployment descriptor or URL mapping. A wrong servlet name, missing class, or invalid XML structure can stop the application from starting correctly.
Review these items
- the
web.xmlfile syntax - servlet class names
- URL pattern mappings
- filter mappings
- listener definitions
Even a small XML typo can cause the app to fail during deployment. If you recently edited web.xml, validate the structure carefully. If the app uses annotations instead of XML, confirm that the package names and class names are still correct after the build.
Check file and folder permissions
In managed JSP hosting, permissions problems can surface as 500 errors when Tomcat cannot read the application, write temporary files, or access required resources. This often happens after uploading files from a local machine or after moving an application between environments.
What to verify
- the application folder is readable by the web service user
- temporary directories are writable
- uploaded JSP, class, and JAR files have correct permissions
- configuration files are not accidentally locked down
- no file ownership changed during transfer
As a general rule, the app server must be able to read the deployed application and write to any directories it needs for temp files, logs, cache, sessions, or uploads. If a feature works locally but fails in hosting, permissions are one of the first things to inspect.
Review dependencies and missing libraries
Many JSP applications fail with a 500 error because a required library is missing from WEB-INF/lib or from the runtime classpath. This is common after a build change or when a developer tests with a local IDE that provides libraries not actually bundled in the deployment package.
Common dependency issues
- missing JDBC driver
- missing framework JAR
- version mismatch between libraries
- duplicate classes in different JARs
- library compiled for a different Java version
When a dependency problem happens, the error page may show a generic 500 to visitors, but the logs usually contain a clear exception such as ClassNotFoundException or NoSuchMethodError. The fix is usually to rebuild the WAR with the correct library set.
Check database connectivity if the app depends on data
If your JSP application uses a database, a broken connection can cause a 500 error on the first page that tries to load data. The application may start correctly but fail when a request needs a database query.
Check the following
- database host, name, username, and password
- JDBC URL syntax
- database server availability
- connection pool settings
- credentials stored in environment files or config files
If the error began after a password change, hostname change, or database migration, test the connection string first. A valid JSP page may still throw a 500 if the data source is unreachable.
Inspect memory usage and limits
A private JVM or Tomcat instance can still fail if the app uses more memory than the current service allocation allows. This is common with large JSP applications, heavy reports, file uploads, or applications that load many classes at startup.
Signs of memory-related failure
- the app server starts, then fails during load
- pages work briefly and then return 500 errors
- logs show
OutOfMemoryError - startup becomes slower after each deployment
If the hosting plan includes resource limits, review them in the service settings. You may need to reduce JVM memory usage, optimize the application, or simplify startup tasks. A restart can help temporarily, but if memory pressure is the underlying issue, the error will return.
Check for broken startup code or initialization errors
Some JSP applications fail before serving any pages because an initialization block, listener, or startup task throws an exception. In that case, the app server may be running but the application context is not fully available.
Examples of startup failures
- servlet context listener throws an exception
- configuration file cannot be read
- environment variable is missing
- cache directory cannot be created
- external service timeout during initialization
If the app uses startup logic, try disabling non-essential initialization steps temporarily. Keep the application as simple as possible until you identify the line that triggers the failure.
Compare Apache, Tomcat, and application-level errors
In JSP hosting, a 500 error may originate at different layers. Knowing where it appears helps you troubleshoot faster.
If Apache shows 500
The request may be passed to Tomcat through a connector or proxy, but the upstream app server returned an error. Check the Tomcat logs and the application logs first.
If Tomcat shows 500
The servlet container received the request and the problem is inside the JSP, servlet, or app configuration. Review the stack trace and deployment state.
If the app works from one URL but not another
That usually points to a route-specific issue such as bad parameters, a controller problem, or a page that loads missing data.
Use a step-by-step troubleshooting flow
If you want a practical order of work, use this sequence:
- Confirm the app server and Tomcat service are running.
- Check the latest logs for a clear stack trace.
- Test with a very simple JSP page.
- Verify the Java version selected in Plesk.
- Review deployment paths, WAR contents, and file permissions.
- Check
web.xmland servlet mappings. - Inspect missing JARs, classpath problems, and dependency versions.
- Test database connectivity if the app uses one.
- Review memory usage and any service limits.
- Restart the application only after checking the logs, not before.
This approach avoids random changes and helps you identify the root cause faster.
When to redeploy the application
Redeploying can fix corrupted or incomplete deployments, especially after an interrupted upload or a build package problem. However, redeploying is most useful when the logs point to missing files, stale classes, or bad deployment artifacts.
Before redeploying:
- remove old compiled classes if your build process can regenerate them
- rebuild the WAR from a clean source tree
- confirm the target Java version
- package all required JAR files
- test the archive locally if possible
If a fresh deploy still produces the same 500 error, the cause is likely configuration, runtime, or code-related rather than a damaged upload.
Using My App Server in a Plesk hosting environment
With a Java hosting setup based on My App Server, you can manage a private JVM and Apache Tomcat instance within your hosting account. This is useful for JSP, servlet, and WAR-based apps that need more control than standard static hosting.
For troubleshooting, this kind of setup is helpful because you can usually:
- select or switch Java versions
- start, stop, and restart the service
- deploy or redeploy your application
- inspect logs more easily
- test changes without affecting other customers
If your app is built for small or medium Java workloads, this is often enough control to resolve most 500 errors without complex server administration. For heavier enterprise patterns such as clustering or advanced high-availability design, a different platform is usually more appropriate.
Frequently asked questions
Is a 500 error always caused by Tomcat?
No. Tomcat is one common source, but the cause can also be JSP syntax, missing libraries, permissions, database connectivity, Java incompatibility, or broken startup code.
Why does my JSP page work locally but fail on hosting?
Local development environments often have different Java versions, extra libraries, relaxed permissions, or embedded containers. Hosting is stricter, so missing dependencies or incorrect configuration become visible as 500 errors.
Can a wrong Java version cause a 500 error?
Yes. A mismatch between the runtime Java version and the app’s build target can cause startup failures, class loading errors, or JSP compilation problems.
What should I check first after a new deploy?
Check the logs, verify the deployment package, confirm the app server is running, and test a simple JSP page. Those four steps usually narrow down the problem quickly.
Can file permissions really break JSP hosting?
Yes. If Tomcat cannot read application files or write to required temporary folders, requests may fail with a 500 error even if the application code is correct.
Should I restart Tomcat before checking logs?
It is better to check the logs first. Restarting can clear temporary state, but it may also remove useful startup errors from memory if the logs are not reviewed first.
Conclusion
A 500 error on JSP hosting is usually a sign that the application, not the browser, needs attention. In a Plesk-managed Java hosting environment with My App Server, the most effective troubleshooting path is to check logs, confirm the Tomcat or private JVM service, verify Java compatibility, review deployment integrity, and test for JSP compilation, dependency, database, permission, or memory problems.
If you follow the steps in this guide in order, you can usually identify whether the issue is in the app code, the runtime configuration, or the deployment package. That makes it much easier to restore the site quickly and keep the fix focused.