A failed JSP deployment on shared hosting usually means the application did not start correctly inside Tomcat, the Java version does not match the app’s requirements, the WAR file is incomplete, or the deployment path and service settings in Plesk are not configured as expected. In a managed hosting environment, the fastest way to fix the problem is to check the startup logs, verify the application structure, confirm the selected Java/Tomcat version, and make sure the app has the permissions and resource limits it needs.
If you are using a Java hosting setup with a private JVM or a Tomcat instance managed through a control panel extension such as My App Server, most deployment failures can be resolved without changing the hosting account itself. The key is to identify whether the issue is caused by the application package, the runtime configuration, or a service-level startup error.
Common reasons a JSP deployment fails
On shared hosting, JSP deployment failures are usually caused by one of the following:
- Incorrect Java version for the application
- Tomcat version not compatible with the app
- Invalid or incomplete WAR package
- Missing
WEB-INFstructure or deployment descriptors - Startup errors in
web.xml, servlets, or JSP compilation - Port conflicts or service startup issues
- File permission problems in the application directory
- Insufficient memory, disk space, or process limits
- Broken links to external libraries or classpath errors
- Application paths that do not match the deployed context
In a Plesk-based environment, these problems often appear as a failed deployment, a stopped service, a blank page, a 500 error, or a Tomcat startup loop. In some cases the application deploys, but JSP pages do not compile because the server cannot load a required class or the application expects a different servlet/JSP API version.
Check the deployment logs first
The most useful step is to inspect the logs before changing anything else. A failed JSP deployment almost always leaves a message that points to the real cause. In a hosted Tomcat environment, check both the application logs and the service logs.
What to look for in the logs
SEVEREorERRORmessages during startup- Class not found or
NoClassDefFoundError - JSP compilation errors
java.lang.UnsupportedClassVersionErrorjava.lang.OutOfMemoryError- XML parsing errors in
web.xmlor Spring configuration files - Port bind failures such as “Address already in use”
If you are using My App Server in Plesk, open the service and application logs from the control panel and review the last startup attempt. A Tomcat deployment problem is usually visible there immediately. If the log message names a file or class, focus on that item first rather than redeploying repeatedly.
Verify that the WAR file is valid
A large number of failed JSP deployments come from an invalid WAR archive. The archive may be missing required directories, contain nested folders created by the wrong export method, or include files that the application server cannot unpack correctly.
Expected WAR structure
A standard JSP or servlet application should normally include:
WEB-INF/WEB-INF/web.xmlif the app uses itWEB-INF/classes/for compiled classesWEB-INF/lib/for JAR dependencies- JSP files in the application root or in a valid subdirectory
If the archive contains an extra top-level folder, Tomcat may deploy the app under an unexpected context path. For example, if the WAR expands to /myapp/myapp/WEB-INF instead of /myapp/WEB-INF, the application can appear to fail or route to the wrong location.
How to fix a bad package
- Rebuild the WAR from the project output folder, not from the source tree
- Remove duplicate nested directories before packaging
- Confirm that all JAR files are present in
WEB-INF/lib - Make sure compiled classes are placed in
WEB-INF/classes - Test the WAR locally by unpacking it and checking the folder structure
If your hosting platform allows file manager access in Plesk, you can unpack the archive manually and compare the structure against a known good deployment.
Match the Java version to the application
One of the most common JSP hosting errors is a Java version mismatch. An application compiled for a newer Java release will not start on an older runtime. The error often appears as UnsupportedClassVersionError or a startup failure in Tomcat.
What to check
- The Java version used to compile the application
- The Java version selected for the service in Plesk
- The Tomcat version required by the app
- Any framework-specific requirements, such as Spring or Jakarta EE dependencies
With My App Server, you can often select from several ready-to-install Java/Tomcat versions. If your application was built with a newer Java release, install or switch to a compatible runtime version before redeploying. If the application was built for an older Java release, verify that it does not depend on deprecated APIs that were removed from newer platforms.
Symptoms of a version mismatch
- The application deploys but Tomcat stops during initialization
- JSP pages compile partially, then fail with class loading errors
- Deployment succeeds locally but fails on the hosting account
- The log mentions bytecode version, class format, or missing runtime classes
When in doubt, rebuild the application for the Java version available in your hosting plan or switch the service to the Java version that matches the app. This is often the fastest fix in shared hosting environments.
Confirm Tomcat compatibility and application configuration
JSP applications rely on the servlet container, so the Tomcat version matters. A deployment can fail if the app expects a different servlet API, a newer Jakarta namespace, or features not available in the installed runtime.
Check these compatibility points
- Tomcat major version
- Servlet API and JSP API compatibility
- Whether the app uses
javax.*orjakarta.*packages - Framework version support
- Any custom container settings required by the app
For example, older applications may expect javax.servlet classes, while newer applications built for the Jakarta ecosystem require a container that supports jakarta.servlet. If the wrong Tomcat version is selected, deployment may fail immediately or the app may start and then throw class loading exceptions when a JSP is requested.
Inspect web.xml and startup configuration
If the WAR structure is correct and the runtime version is compatible, the next place to check is the application configuration. Small XML mistakes can stop deployment completely.
Typical configuration errors
- Malformed XML in
web.xml - Duplicate servlet definitions
- Invalid filter or listener class names
- Wrong welcome file entries
- Incorrect context parameters
- Broken references to environment entries or resources
In JSP hosting, a startup error in web.xml often produces a generic deployment failure, even though the real issue is a single invalid line. Review the deployment log carefully, then open the configuration file and compare the line number with the error output.
If your application uses annotations instead of web.xml, make sure the annotated classes are compiled and packaged correctly. A missing dependency or scan error can still prevent startup.
Check file permissions and ownership
On shared hosting, the application may fail to start if Tomcat cannot read or write the required files. This is especially common when files were uploaded via FTP from another environment or generated on a different server.
Permissions to review
- Readable access to JSP, class, and JAR files
- Write access to log or temp directories if the app creates them
- Correct ownership for uploaded files
- No blocked execution on scripts or helper binaries used by the app
Make sure the application directory is not too restrictive. If Tomcat cannot read a JSP file or cannot create temporary files, the deployment may appear to fail or the application may start with partial functionality only.
Review memory, limits, and service status
Shared hosting has resource limits, so a JSP application can fail simply because it needs more memory or startup time than the current service profile allows. This is not unusual during first deployment, especially with frameworks that load many classes at startup.
Resource-related causes
- Java heap too small for the application
- Service startup timeout
- Disk quota reached
- Too many files in the deployment
- Temporary directory full
In My App Server, service control options let you start, stop, and restart the private JVM/Tomcat instance from Plesk. If the service is not running, restart it and review the latest logs. If the application fails after a restart but worked before, check whether the current deployment exceeds the available limits for your plan.
If your logs show OutOfMemoryError, the application may need a higher memory allocation or a lighter startup profile. Keep in mind that shared hosting is designed for smaller and medium-sized JSP and servlet applications, not for heavy enterprise clusters.
Redeploy cleanly after fixing the issue
After correcting the root cause, do a clean redeployment instead of overwriting only part of the application. Leftover files from a previous version can cause the same startup failure to return.
Recommended redeploy process
- Stop the application service if your control panel allows it
- Remove the previous deployment directory or undeploy the app
- Upload the corrected WAR file
- Verify the selected Java and Tomcat version
- Start the service again
- Check the logs immediately after startup
If the hosting platform offers a deploy button or application manager, use it rather than copying files manually into the runtime directory. That reduces the chance of incomplete extraction or leftover classes from older builds.
How to troubleshoot specific JSP deployment errors
UnsupportedClassVersionError
This means the application was compiled with a newer Java version than the server supports. Fix it by selecting a compatible Java version in Plesk or recompiling the app for the available runtime.
ClassNotFoundException or NoClassDefFoundError
A required library is missing or not packaged correctly. Check WEB-INF/lib, verify the build process, and confirm that no external dependency is only available on your local machine.
JSP compilation errors
The JSP file may contain syntax errors, missing tag libraries, or incompatible imports. Review the exact line referenced in the log and test the page locally if possible.
500 Internal Server Error after deployment
The application started, but a runtime problem occurs when the JSP is requested. This can still be caused by configuration, missing data sources, invalid imports, or a classpath issue.
Tomcat fails to start
Look for port conflicts, damaged configuration files, invalid server settings, or memory exhaustion. Restart the service only after correcting the underlying cause.
Best practices for JSP hosting on shared platforms
To reduce deployment failures in the future, keep the application package and server configuration simple and consistent.
- Use one known Java version for build and deployment
- Keep Tomcat and application requirements aligned
- Package the application as a clean WAR
- Test the app locally before uploading
- Monitor log output after every deployment
- Remove unused libraries from
WEB-INF/lib - Avoid hardcoded local paths
- Use the control panel to manage service restarts and version selection
These practices are especially useful in managed JSP hosting environments where the goal is reliable deployment rather than complex server administration.
When to contact support
Contact support if the deployment still fails after you have checked the WAR structure, Java version, Tomcat version, logs, and permissions. Include the following information to speed up troubleshooting:
- The application name and deployment path
- The selected Java and Tomcat version
- The full error message from the log
- Whether the app was deployed as a WAR or as unpacked files
- Any recent changes to dependencies or configuration files
This helps isolate whether the issue is specific to the application package or related to the service configuration in the hosting account.
FAQ
Why does my JSP app deploy locally but fail on shared hosting?
Local and hosted environments often use different Java and Tomcat versions. The hosted account may also have stricter memory, permission, or file structure limits. Check compatibility first.
Can I run a private Tomcat instance on shared hosting?
Yes, in a Java hosting setup with My App Server you can manage your own Tomcat or private JVM inside the hosting account, within the available service limits.
What should I check first when deployment fails?
Start with the logs. They usually show whether the issue is a Java mismatch, a missing class, a bad XML file, or a resource problem.
Why is my WAR file deployed but the JSP pages still do not load?
The application may have started partially, but JSP compilation or runtime class loading is failing. Review the logs for missing dependencies, import errors, or JSP syntax problems.
Do I need to edit Tomcat files manually?
Usually no. In a managed hosting setup, it is better to use the control panel to select versions, restart the service, and deploy the application. Manual edits should be limited to application-level configuration unless support instructs otherwise.
Can an empty log mean the deployment was successful?
Not always. Some failures appear only when the first JSP request is processed. If the application starts but pages return errors, check the access log and application log after loading the page.
Conclusion
To fix a failed JSP deployment on shared hosting, focus on the most common causes in order: check the logs, validate the WAR structure, confirm the Java and Tomcat versions, review web.xml and classpath settings, and make sure the service has enough resources and correct permissions. In a Plesk-based Java hosting environment with My App Server, most JSP and servlet deployment problems can be solved quickly through the control panel by selecting the right runtime and redeploying a clean package.
If the application still does not start, the log file will usually reveal the exact missing dependency, configuration error, or runtime mismatch. Fix that root cause, redeploy once, and verify the application again before making further changes.