If your JSP application is packaged as a build archive, the deployment process on a managed hosting platform is usually straightforward: upload the package, place it in the correct web application directory, and make sure the Java runtime and Tomcat service are configured to load it correctly. On a Plesk-based Java hosting account with My App Server, this typically means using your private Apache Tomcat instance and deploying a WAR file or an extracted application build in the right location.
This guide explains how to deploy a build package for JSP hosting, what file types are commonly used, how deployment works in a control panel environment, and what to check if the application does not start after upload.
What a build package means in JSP hosting
In JSP hosting, a build package is the compiled and deployable version of your web application. It usually contains the application classes, JSP files, static resources, configuration files, and any required libraries. Most often, the package is delivered as a WAR file, although some teams also deploy extracted application folders or custom build outputs generated by Maven, Gradle, or another build tool.
For hosted Java applications, the build package must match the runtime environment. That means the package should be compatible with the selected Java version, the installed Tomcat version, and the hosting account limits. A package that works locally may still fail on the server if it depends on a newer Java runtime or on a library that is not included in the build.
Supported deployment formats
On a typical JSP hosting platform, the following deployment formats are the most common:
- WAR file - the standard package for Java web applications and JSP applications.
- Exploded application directory - an extracted folder structure containing the application files.
- Custom build output - a package produced by your build system and then adapted for Tomcat deployment.
If you use My App Server, a WAR package is usually the easiest and most predictable option because Tomcat can deploy it directly. In some cases, an extracted structure is useful for troubleshooting or for applications that need manual file adjustments before deployment.
Before you upload the package
Before deploying a build package to your JSP hosting account, check a few important details to reduce the chance of deployment errors.
Confirm the Java version
Make sure the application was compiled for the same Java version that your hosting account uses. If your app depends on features from a newer JDK, update the runtime selection in Plesk or rebuild the application for a compatible version.
Check the Tomcat version
Different Tomcat versions support different servlet and JSP specifications. If your application was built for a specific Tomcat release, confirm that the hosted service uses a compatible version. My App Server allows you to work with ready-made Tomcat versions and, in some cases, custom application server setups.
Verify package completeness
Your archive should include everything needed to start the application:
- compiled classes
- JSP files
- static assets such as CSS, JavaScript, and images
- library JAR files
- deployment descriptors such as
web.xmlif required
If a dependency is missing, the application may deploy but fail at runtime with class loading or initialization errors.
Review external configuration
If your application relies on environment-specific values such as database credentials, API keys, or file paths, confirm that those settings are already defined for the hosted environment. A package may upload correctly but still fail if it expects local development settings.
How deployment works in a managed JSP hosting environment
In a managed hosting setup with Plesk and My App Server, deployment usually happens through the control panel rather than by direct server access. This gives you practical control over your application while keeping the environment managed and isolated within your hosting account.
The general workflow is:
- Select or install the required Java/Tomcat version.
- Upload the build package to the application directory or deploy it through the control panel.
- Let Tomcat unpack and load the package.
- Check service status, logs, and application URL.
- Fix configuration issues if the app does not start.
This approach is suitable for JSP hosting, Tomcat hosting, servlet hosting, and smaller Java applications that need a private JVM without the complexity of enterprise application server administration.
Step-by-step: how to deploy a build package for JSP hosting
1. Prepare the build locally
Start by generating a production-ready build. If you use Maven, Gradle, or a similar tool, create the final archive as part of your release workflow. Remove development-only files, confirm that the package contains the correct context path structure, and make sure no local-only paths are hardcoded into the application.
For a WAR deployment, the archive name often determines the default application name. For example, myapp.war may deploy as /myapp unless your Tomcat or control panel configuration maps it differently.
2. Select the Java runtime and app server version
In Plesk, open the My App Server extension and choose the Java/Tomcat combination that matches your application. If your app was built for a specific runtime, pick that version before deployment. This is especially important for JSP applications that use newer servlet APIs or libraries compiled for a certain Java level.
If you are unsure which version to use, start with the version recommended by your application documentation or build configuration. Avoid deploying to a mismatched runtime and hoping it will work, because that often leads to startup errors that are harder to trace later.
3. Upload the package
Upload the WAR file or build archive through the control panel file manager, deployment interface, or your preferred secure upload method if available. Some hosting platforms also support FTP or SFTP for the upload step, but the package still needs to end up in the correct location for Tomcat to recognize it.
In many JSP hosting setups, the deployment directory is linked to the service configuration inside Plesk. If the platform offers a dedicated deploy action, use that rather than copying files manually, because it reduces the risk of using the wrong path or leaving stale files behind.
4. Deploy to the correct application root
Make sure the archive is deployed into the web application root expected by Tomcat. With My App Server, the service is configured to run the application inside your hosting account, using a private JVM and a dedicated Tomcat instance. That means the package should be placed where the app server can unpack and serve it.
If you upload an extracted directory instead of a WAR file, check that the folder structure is valid for a Java web app. A typical structure includes WEB-INF, JSP pages, and static assets in the right locations.
5. Wait for Tomcat to unpack and start the application
After upload, Tomcat may unpack the package automatically. This can take a short time depending on the archive size and the number of included libraries. Once unpacking is complete, the application should become available at its assigned URL.
If the application does not appear immediately, refresh the service status in the control panel and review the logs before uploading the package again. Repeated uploads without checking logs can overwrite useful error information.
6. Test the application URL
Open the application URL in a browser and verify the main pages, JSP rendering, form submissions, and any API endpoints exposed by the web app. Test static assets as well, since missing CSS or image files can make a deployed app look broken even if the backend starts correctly.
If the application uses a context path, confirm that the URL matches the deployed path. A common issue is uploading a package correctly but accessing it at the wrong URL.
Deploying WAR files vs extracted builds
WAR file deployment
WAR deployment is the simplest option for most JSP hosting use cases. The archive contains the web application in a format that Tomcat understands natively. This reduces deployment steps and is usually the most stable approach for routine releases.
WAR deployment is a good fit when:
- you want a repeatable release process
- the application is already built for Tomcat
- you need simple redeployments after updates
- you prefer a clean package instead of manual file copying
Extracted application deployment
An extracted directory can be useful when you need to inspect files on the server or troubleshoot a deployment issue. It may also help if you need to replace a small part of the application without rebuilding the whole archive, although this is usually less reliable than redeploying a full WAR file.
Use this format carefully. A partial file update can leave stale classes or resources behind, especially if Tomcat has already cached a previous version of the app.
Common deployment problems and how to avoid them
Wrong Java version
If the application was compiled for a newer Java version than the runtime supports, the app may fail during startup with class version errors. Always match the build target to the runtime configured in My App Server.
Missing libraries
If third-party JARs are not included in the package, Tomcat may load the application but fail when a page or servlet tries to use them. Review the build output and make sure all required dependencies are packaged correctly.
Invalid context path
Sometimes the application deploys, but the URL does not resolve because the context path is different from what you expect. Check the archive name, deployment settings, and any context configuration used by Tomcat or Plesk.
Permission or file ownership issues
If uploaded files are not readable by the application service, the app can fail to start or serve resources incorrectly. Managed hosting platforms normally handle permissions automatically, but manual uploads or custom extraction steps can still introduce problems.
Leftover files from a previous release
When replacing an application, old compiled classes or resources can remain in the deployment directory and interfere with the new package. A clean redeploy is often better than overwriting only part of the existing installation.
Configuration not updated for production
Applications that work in development often fail after deployment because they still point to local databases, local file paths, or test credentials. Review the production configuration before uploading the package.
Best practices for reliable JSP package deployment
To keep deployment predictable on a managed JSP hosting platform, follow a few simple practices:
- build one production archive for each release
- keep the Java version consistent between build and runtime
- deploy WAR files when possible
- check Tomcat logs after every release
- use environment-specific configuration outside the codebase where possible
- avoid manual file edits in the live deployment directory unless you are troubleshooting
- test the application after each upload, including login, forms, and JSP rendering
If your hosting account uses My App Server, the control panel makes it easier to manage a private JVM and application server instance without needing full server administration. That is especially useful for small and medium JSP applications that need a practical deployment workflow rather than a complex infrastructure layer.
How to update an existing deployed package
When you release a new version of an existing JSP application, the safest method is usually a full redeploy of the new archive. This reduces the chance of old classes or resources remaining from the previous version.
- Stop the application service if required by your deployment process.
- Upload the new WAR or build package.
- Replace the previous deployment completely.
- Start or reload the service.
- Confirm the version and run a smoke test.
If your application stores user uploads or runtime-generated files inside the same directory as the deployed app, separate those files first. Otherwise, a redeploy may remove data that should persist between releases.
Logs and checks after deployment
After each deployment, review the application and Tomcat logs. These logs usually show parsing problems, missing classes, startup exceptions, and misconfigured resources much faster than the browser does.
Useful checks include:
- Tomcat startup status
- deployment success messages
- JSP compilation errors
- database connection failures
- resource path errors
- unexpected redirects or HTTP 500 responses
If your hosting platform offers service control in Plesk, use it to confirm that the app server is running normally after each upload. A package that is technically deployed but not running correctly still needs troubleshooting before it can be considered successful.
FAQ
What file type should I use for JSP hosting?
In most cases, use a WAR file. It is the standard deployment format for Tomcat and is usually the easiest way to deploy a JSP application on managed hosting.
Can I upload a compiled Java project directly?
You can upload a build package, but it still needs to be in a Tomcat-compatible format. A compiled Java project by itself is not enough unless it is structured as a web application with the required JSP and deployment files.
Why does my application deploy but show an error page?
This often means the archive uploaded correctly, but the application failed during startup. Common reasons include missing libraries, Java version mismatches, incorrect configuration, or database connection problems.
Should I use WAR or an extracted folder?
WAR is usually the better choice for stable deployments and repeatable releases. Use an extracted folder mainly for troubleshooting or special cases where manual file-level control is needed.
Can I use a custom Tomcat version?
In a My App Server environment, ready-made Java and Tomcat versions are available, and some custom application server setups can also be configured. The best choice depends on your application requirements and the service options available in the control panel.
What if my app needs a different Java version later?
You can usually switch the runtime in the hosting control panel and redeploy the package, as long as the application is compatible with that Java release. Always test after the change.
Conclusion
Deploying a build package for JSP hosting is mostly about matching the package to the runtime environment and placing it in the correct Tomcat deployment path. With a managed hosting platform and My App Server, you can run your own Apache Tomcat instance, choose a suitable Java version, and deploy WAR or build packages through Plesk with less manual server work.
For the best results, build clean packages, keep Java and Tomcat versions aligned, upload to the right application root, and review logs after every release. That workflow is practical, reliable, and well suited to JSP, servlet, and small-to-medium Java hosting projects.