Before uploading a new JSP release, it is worth checking a few practical details in the hosting panel, the application package, and the Tomcat runtime itself. In a managed Java hosting environment, small mistakes such as an incorrect Java version, a missing context path, a file permission issue, or an upload to the wrong directory can prevent the new build from starting cleanly. A short release checklist helps reduce downtime, makes troubleshooting faster, and ensures your JSP or servlet application behaves the same after deployment as it did in testing.
If your hosting account uses a control panel such as Plesk with a Java hosting extension like My App Server, you can usually manage a private Tomcat instance, select an available Java version, and deploy WAR-based applications or manually uploaded JSP builds. That flexibility is useful, but it also means a release should be reviewed before you replace the existing version. The checklist below is designed for JSP hosting, Tomcat hosting, servlet hosting, and small to medium Java applications running in shared hosting with a private JVM.
Check the release package before you upload
Start with the package itself. A release that looks correct in a local build folder may still be missing configuration files, compiled classes, or static resources once it is packaged for upload. For JSP applications, the most common problems are incomplete archives, wrong directory structure, and stale build output left behind from previous builds.
Confirm the package type
Make sure you know whether you are uploading a WAR file, a ZIP archive, or a folder containing application files. In Tomcat hosting, a WAR package is usually the most reliable option because it keeps the application structure consistent. If you are using a manually uploaded build, confirm that the deployed structure matches what the server expects.
- WAR package: best for standard Tomcat deployment.
- ZIP or folder upload: useful when your hosting workflow requires manual placement of files.
- Mixed build output: avoid uploading development folders that include source files, logs, or temporary artifacts.
Verify the build output is clean
Before uploading, review the build directory and remove temporary files, test resources, IDE metadata, and local configuration that should not go to production. A clean release package reduces the risk of exposing internal settings and avoids confusion when the application starts.
- Remove debug files and local test pages.
- Exclude IDE folders such as project metadata.
- Check for duplicated JSPs or old class files.
- Confirm that the package contains only the version you want to publish.
Check file names and versioning
Use clear version numbers in your release name. This makes rollback easier if the new build needs to be replaced quickly. A release name such as app-1.8.3.war is much easier to track than a generic name like latest.war. Versioned naming also helps when you keep multiple packages during testing.
Confirm Java and Tomcat compatibility
One of the most important checks before uploading a new JSP release is compatibility with the Java runtime and the Tomcat version in your hosting account. A build compiled for a newer Java version may not start on an older JVM. Likewise, a web application that works on one servlet container may require a different configuration on another.
Match the Java version to the build
In My App Server, you may be able to select from available Java versions or install a specific Tomcat/Java combination. Before upload, verify which JVM version the application was compiled against and which version is active in the hosting panel. If your build uses newer language features, class file versions, or third-party libraries, make sure the selected Java runtime supports them.
- Check the Java version used in your build pipeline.
- Confirm the runtime selected in the control panel.
- Test any framework dependencies against that runtime.
- Avoid assuming that a local JDK matches the hosted JVM.
Review Tomcat-specific requirements
Tomcat handles JSP and servlet applications well, but your project may depend on specific context settings, session handling behavior, or server-side encoding defaults. If you use custom filters, servlets, or application listeners, verify that they are compatible with the Tomcat version available in the hosting platform.
- Check the supported Tomcat release.
- Verify any required context.xml or web.xml settings.
- Confirm session timeout and request encoding requirements.
- Review framework compatibility, especially for older JSP code.
Review application configuration before release
Many JSP releases fail not because the code is broken, but because configuration values are wrong for the production host. Before you upload, review any properties, environment values, or XML settings that control database access, file storage, email delivery, and external API connections.
Check production endpoints and credentials
Make sure the release points to production services, not local or staging resources. This is especially important if the application reads database URLs, SMTP settings, or API keys from config files bundled with the release.
- Confirm database host, name, user, and password.
- Review mail server settings if the app sends notifications.
- Update any external API endpoints.
- Remove hard-coded test credentials from the package.
Verify context path and application name
In a hosted Tomcat environment, the deployment path can affect routing, links, and session behavior. If your application expects to run under a specific context path, verify that the uploaded package name and deployment target match that expectation. A mismatch can lead to broken links, missing resources, or redirect loops.
- Check the deployed context path in the control panel.
- Confirm links, form actions, and redirects use the correct base path.
- Test resource loading for CSS, JS, images, and JSP includes.
Review permissions and writable directories
Some JSP applications need write access for uploads, generated reports, session data, or cached content. Before releasing, verify which directories must be writable and whether the hosting account allows them. In a managed hosting setup, permissions should be kept as narrow as possible while still allowing the application to function.
- Check upload directories.
- Confirm log and cache paths.
- Ensure the application is not writing into protected source directories.
- Use the least access needed for normal operation.
Back up the current version first
Never upload a new JSP release without keeping a rollback path. Even a well-tested build can fail after deployment because of an environment-specific dependency, a configuration mismatch, or an overlooked browser issue. A simple backup of the current working version can save time and prevent unnecessary downtime.
Save the previous package
Keep the last stable WAR or application folder before replacing it. If your release process uses versioned archives, do not overwrite the existing file immediately. Instead, archive it with a clear timestamp or release number.
Export critical configuration
If configuration is stored partly outside the package, save copies of any server-side settings, context files, or custom Tomcat configuration entries that are relevant to the application. This is useful when the release changes dependencies or server-side behavior.
- Archive the previous application package.
- Save configuration files separately.
- Document the active Java version and Tomcat version.
- Keep notes about any custom deployment steps.
Check the deployment method in Plesk or My App Server
Hosting platforms that provide a Java control panel often support more than one deployment approach. Before you upload the new release, confirm the method you plan to use: direct upload through the panel, replacement of an existing package, or manual deployment to an application directory. In My App Server, managing your own Apache Tomcat instance inside the hosting account gives you flexibility, but the upload method still needs to match the current setup.
Confirm whether the app is managed or custom
If you use one of the ready-made Java or Tomcat setups, deployment may be simpler because the platform handles the service and runtime selection. If you use a custom app server setup, verify the upload path, startup options, and runtime settings before replacing the build.
- Check whether the application uses a standard Tomcat install or a custom app server.
- Review the service control screen in the hosting panel.
- Confirm whether the deployment folder is tied to a specific instance.
- Make sure you are not uploading to the wrong environment.
Check service status before upload
Before replacing a live package, see whether the Tomcat service should be stopped, restarted, or left running during the upload. For some applications, a brief stop is safer because it prevents file locking or partial reads during the transfer. For others, especially when using atomic replacement, the service can stay up until the new package is ready.
- Check whether the service is running.
- Review the expected restart behavior after deployment.
- Plan the change window if the app is already in use.
Validate database and external service dependencies
JSP applications often depend on a database, file storage, SMTP relay, or another external service. A new release may introduce schema changes, new queries, or library updates that require validation before upload. If those dependencies are not checked, the app may start but fail as soon as the first request reaches a changed code path.
Check database schema compatibility
If the release includes new tables, columns, or query changes, confirm that the schema on the hosted database matches the new code. If the release is not backward compatible, plan the database update carefully so the app does not break during transition.
- Review migration scripts.
- Confirm the release works with the current schema version.
- Avoid deploying code that expects an unapplied migration.
Test external integrations
Make sure payment gateways, email services, authentication providers, or web services still accept connections from the hosted environment. In managed hosting, outbound access can be limited by policy or by service configuration, so it is better to verify this before a full release.
Inspect logs and release notes before switching traffic
Good release hygiene includes checking the application logs and reading the build notes before sending users to the new version. This helps you spot deprecations, changed endpoints, or warnings that should be fixed now instead of after a support incident.
Read known issues in the release notes
If your project includes release notes, read them before deployment. Look for configuration changes, migration steps, or required cache resets. Even a minor JSP update may introduce a new parameter or require updated tag libraries.
Review previous log warnings
If the current version already produces warnings, fix them before releasing the next build if they are related. Deploying on top of an unstable baseline makes troubleshooting harder. Keep an eye on class loading issues, missing resources, and JSP compilation warnings.
Check static resources and JSP includes
JSP releases often fail because a page includes files that were not moved into the new package. If your application uses shared headers, custom tag files, image assets, or JavaScript bundles, confirm that all referenced resources are present and paths are still correct.
Verify includes and tag files
Review all JSP include statements, tag libraries, and custom components. If a file moved, was renamed, or was excluded from the package, pages can break after deployment even when the application starts successfully.
- Check shared header and footer files.
- Confirm custom tag library paths.
- Review JSP fragments and include directives.
- Test all page templates that rely on shared resources.
Check resource paths for the hosted environment
Absolute paths that work locally may not work on the hosting account. Use relative paths or application-aware base paths where possible. This is especially important after a release if the context path changes or if the app is deployed under a different folder name.
Plan the release window and rollback
Even in a small or medium JSP hosting setup, it is smart to plan when the upload happens. Deploying during peak traffic increases the chance that users will see a temporary error if the new package needs time to initialize or the Tomcat service must restart.
Choose a low-traffic period
If possible, upload the new release during a quiet period. This reduces the impact of short restarts and makes it easier to watch the application after deployment.
Prepare a rollback step
Decide in advance how you will revert if the release does not start. A rollback can be as simple as restoring the previous WAR file, replacing a folder, or switching back to the older version in the panel. The main goal is to make recovery quick and predictable.
- Keep the previous stable package ready.
- Know how to restore it in the control panel.
- Document any database rollback limitations.
- Test the rollback procedure at least once in staging if possible.
Practical pre-upload checklist
Use this short checklist before every JSP release upload:
- The package is clean and contains only production files.
- The release uses the correct Java version.
- The Tomcat version supports the application.
- Configuration values point to production services.
- The context path and file paths are correct.
- Writable directories are defined and permitted.
- The previous stable release is backed up.
- The deployment method in Plesk or My App Server is confirmed.
- Database changes are compatible with the new build.
- Rollback steps are ready if the deployment fails.
What to verify after the upload
The release check does not end when the upload finishes. After deployment, confirm that the application starts correctly and that the main user flows work as expected. A quick post-upload check can catch problems before they affect all users.
- Open the application home page and key JSP pages.
- Check logs for startup errors or warnings.
- Verify database login and session creation.
- Test forms, uploads, and redirects.
- Confirm static resources load correctly.
- Restart the service only if the deployment procedure requires it.
FAQ
Should I upload a WAR file or a folder for a JSP release?
For most Tomcat hosting setups, a WAR file is the safest option because it preserves the application structure and reduces manual errors. A folder upload can work when your hosting workflow is designed for it, but it requires more care with paths, permissions, and consistency.
Why does a JSP release work locally but not after upload?
The most common reasons are Java version mismatch, missing configuration, incorrect context path, file permission issues, or dependencies that were available locally but not on the hosted environment. Always compare the local build assumptions with the actual hosting settings.
Do I need to stop Tomcat before uploading a new release?
Not always, but it depends on the deployment method and whether files are locked during upload. In some cases, stopping the service or using a controlled restart after upload is the safest approach. Check the service control options in your hosting panel before deploying.
How do I know if the Java version is compatible?
Check the JDK version used to compile the application and compare it with the runtime selected in the hosting account. If your code uses features or libraries that require a newer runtime, choose a compatible Java version before uploading the release.
What should I back up before replacing the build?
Keep the previous application package, any custom configuration files, and notes about the active Java and Tomcat versions. If the application uses external configuration outside the package, back that up too.
Can I use My App Server for JSP and servlet applications?
Yes. My App Server is designed for Java hosting through a Plesk extension and is suitable for JSP, servlet, Tomcat, and private JVM use cases. It is a practical option for small and medium applications that need control over the Java runtime and application deployment inside a managed hosting account.
Conclusion
Before uploading a new JSP release, check the package quality, Java and Tomcat compatibility, configuration values, permissions, deployment path, and rollback plan. In a managed hosting environment with Plesk and My App Server, these checks take only a short time but can prevent failed starts, broken pages, and avoidable downtime. A simple release routine also makes future deployments easier because you know exactly which version is running, which runtime it needs, and how to recover if something changes unexpectedly.