When you prepare a JSP application for deployment on a hosting platform, the most important goal is simple: the build should contain everything the application needs to start cleanly on the target Java/Tomcat environment, and nothing that can cause version conflicts, missing resources, or broken paths. In a managed hosting setup with Plesk and a private Tomcat instance such as My App Server, a deployable JSP build is usually a WAR package or an application folder that includes compiled classes, JSP files, static assets, configuration, and only the runtime libraries that are really needed by the app.
If the build is incomplete, the application may deploy but fail at runtime. If it includes the wrong dependencies, it may start with errors, load the wrong classes, or behave differently from your local environment. This article explains what should be included in a deployable JSP build, how to structure it for Tomcat hosting, and how to check it before upload in a control panel environment.
What a deployable JSP build usually contains
A deployable JSP build is the final output of your application packaging process. For most JSP and servlet applications, this means a WAR file that Tomcat can unpack and run automatically. The package should contain the application code, web resources, deployment descriptors, and libraries in the standard web application layout.
At a minimum, a good deployable build should include:
- JSP pages and any server-side view files
- Compiled Java classes for servlets, filters, listeners, and helper code
- Static assets such as CSS, JavaScript, fonts, and images
- Configuration files required by the application
- Dependency libraries in the correct location
- The web application descriptor if your app uses it
In a Tomcat hosting environment, this build should also be compatible with the selected Java version and the servlet API provided by the container. If you use My App Server, that compatibility needs to match the JVM and Tomcat version you selected in Plesk.
Standard WAR structure for JSP hosting
Tomcat expects a recognizable web application structure. The most common deployable format is a WAR archive with a layout like this:
- WEB-INF/ — protected application area
- WEB-INF/classes/ — compiled application classes
- WEB-INF/lib/ — JAR dependencies used by the app
- WEB-INF/web.xml — deployment descriptor, if used
- JSP files — usually outside WEB-INF so they can be requested directly, unless your design loads them through controllers
- static/ or similar folders for assets
This structure matters because Tomcat uses it to locate classes, libraries, and web resources. A build with files placed in the wrong directory may deploy partially, but the application will not behave correctly.
What goes under WEB-INF
The WEB-INF directory is not intended for direct browser access. It is the right place for:
- Compiled .class files
- Application JAR files
- web.xml
- Spring or framework configuration files if they are meant to stay private
- Resource files used only by server-side code
Keeping these files in WEB-INF helps protect internal logic and keeps the deployment clean. If your app is served through a private JVM in a hosting panel, this separation is still the preferred approach.
What usually stays outside WEB-INF
Files that must be reachable by the browser should typically remain outside WEB-INF. These include:
- JSP pages, if they are meant to be directly rendered
- Images and uploaded assets
- JavaScript bundles
- Stylesheets
- Public download files
In many modern apps, JSP files are minimal and most routing is done by servlets or controllers. Even then, the build still needs to include the JSP templates in a location Tomcat can render.
Compiled classes versus source code
A deployable build should include compiled bytecode, not only source files. Source files are useful during development, but Tomcat runs compiled Java classes. If your build process does not package the compiled output, the app will fail because the server cannot execute .java files directly.
Make sure the build includes:
- Compiled servlet classes
- Helper and utility classes
- Custom tag handler classes if used
- Listener and filter classes
In a managed hosting environment, this is particularly important when you upload through Plesk or a similar control panel. The platform expects a ready-to-run build, not a development workspace.
Dependencies and JAR libraries
One of the most common deployment problems in JSP hosting is missing or conflicting libraries. Your application should include all runtime dependencies it needs inside WEB-INF/lib, unless you know the hosting environment already provides a compatible version and you intentionally rely on it.
Include libraries for:
- Frameworks such as Spring, Struts, or JSF if the application uses them
- Database drivers if the app connects to MySQL, PostgreSQL, or another database
- Logging libraries if required by your code
- JSON, XML, and utility libraries
- Custom internal libraries used by the project
Be careful with container-provided libraries. Tomcat already supplies servlet and JSP API components, so these should usually not be bundled inside your application unless a build tool has done so by mistake. Packaging duplicate versions of container APIs can lead to class loading issues.
Common dependency mistakes
- Including servlet-api.jar in the application package
- Bundling multiple versions of the same library
- Forgetting a transitive dependency that is needed at runtime
- Including test-only libraries in the production build
A good rule is to review your final WAR and keep only runtime dependencies that the application needs on the server.
JSP files and view resources
For JSP hosting, the JSP files themselves are a core part of the deployable build. They may be used as pages, fragments, templates, or view files in a servlet-driven application. Ensure they are included in the package in the correct path and with the same case-sensitive names used in code.
Keep an eye on:
- Correct folder paths referenced by forward/include statements
- Case sensitivity on Linux hosting environments
- Relative imports and tag file references
- JSTL or custom tag library declarations
If you move a project from a local Windows environment to a hosting platform, case mismatches are a frequent cause of 404 errors or template resolution failures. For example, Header.jsp and header.jsp are different files on a Linux-based server.
Configuration files that should be included
Many JSP applications need configuration files in addition to code and libraries. These files may control database connections, application settings, logging, or environment-specific behavior.
Examples include:
- application properties files
- XML configuration files
- logging configuration files
- security or permission mappings
- framework-specific context files
When packaging for hosting, make sure configuration files are included if they are required at startup. At the same time, avoid hardcoding local machine values such as development database addresses or file paths that will not exist on the server.
Externalize environment-specific values
It is better to keep environment-specific settings outside the code when possible. In a control panel environment, this makes updates and migrations easier. For example, database credentials, file upload paths, and API keys should be adjusted for the target hosting account rather than baked into the application binary.
If the platform or your deployment process supports external configuration, use it for values that change between local, staging, and production environments.
Static assets and public files
A deployable JSP build should also include every public file the application depends on. Missing CSS or JavaScript files can make an application look broken even if the backend is working correctly.
Typical static assets include:
- CSS files
- JavaScript files
- Images and icons
- Fonts
- PDFs or downloadable documents
For hosting on Tomcat, these files should be placed so the application can serve them directly without extra server-side work. Check that references in JSP pages use the correct context path and relative locations.
Build output versus project source
It is important to distinguish between project source and deployable output. The source tree may contain everything needed to develop the application, but the build output should contain only what the server needs to run it.
A deployable output usually includes:
- Generated class files
- Processed JSP templates
- Packaged libraries
- Resource files ready for runtime
- Deployment descriptors
It should not usually include:
- IDE project metadata
- Test sources
- Unused sample files
- Build caches
- Local configuration with personal paths
Keeping the build clean makes deployments smaller, easier to troubleshoot, and less likely to fail after upload.
How this works in Plesk and My App Server
In a hosting setup with Plesk and My App Server, your deployable JSP build is typically uploaded to a managed Java application instance or a Tomcat-based service configured for your account. The benefit of this setup is that you can deploy a private JVM and control the Java runtime version from the panel without managing the entire server yourself.
In practical terms, this means your build must match:
- The Java version installed for the service
- The Tomcat version selected in the hosting account
- The servlet/JSP API level supported by that container
- Any database or file access permissions available in the account
If your application was built for a newer Java version than the service supports, it may fail to start. If it depends on APIs that are not available in the selected Tomcat version, deployment can fail or the application can behave unpredictably.
Why this matters in a shared hosting context
In managed hosting, the server environment is controlled and predictable, which is good for stability. But it also means your application must be packaged correctly. You usually do not have the freedom to install arbitrary system-wide components, so everything the app needs should be inside the build or compatible with the selected runtime.
Pre-deployment checklist for a JSP build
Before you upload a JSP application, use this checklist to confirm that the build is ready for deployment:
- WAR file or application folder is generated from the final release build
- JSP files are in the correct location
- Compiled classes are present in WEB-INF/classes
- All required JAR files are in WEB-INF/lib
- No duplicate servlet or container API libraries are included
- Static assets are included and paths are correct
- Configuration files are present and point to server-ready values
- File names match case exactly
- The build targets the correct Java version
- The app was tested locally or in staging with the same Tomcat level if possible
If your application uses an external database, confirm that the connection settings are updated for the hosting environment and that the driver JAR is included if needed.
Typical problems caused by incomplete builds
When a JSP build is missing something, the error may appear only after deployment. Common symptoms include:
- ClassNotFoundException due to missing compiled classes or JARs
- NoClassDefFoundError caused by incomplete runtime packaging
- 404 errors for missing JSP pages or static files
- JSP compilation errors due to incompatible tag libraries or APIs
- Database connection failures because the driver or config is missing
- Application starts locally but fails on the hosting server because of Java version differences
These issues are usually easier to prevent than to fix after deployment. A disciplined build process reduces troubleshooting time and makes managed hosting much more reliable.
Best practices for JSP hosting builds
For the best results on a Tomcat hosting platform, follow these practical packaging habits:
- Generate a fresh release build before every deployment
- Keep development-only files out of the deployable package
- Store dependencies in a consistent build system such as Maven or Gradle
- Verify the final WAR contents before upload
- Use server-compatible Java and servlet versions
- Test the application path and context name after deployment
- Keep configuration external where possible
If you use My App Server, it is also helpful to note which Java/Tomcat version your application was built and tested against. That makes future maintenance and upgrades easier from the hosting control panel.
FAQ
Is a deployable JSP build always a WAR file?
Not always, but a WAR file is the standard and usually the safest format for Tomcat hosting. Some environments also support unpacked application folders, but the content requirements are the same.
Should I include source code in the deployment package?
Only if your deployment process specifically requires it. For most hosting setups, the important part is the compiled output and runtime resources, not the full source tree.
Do I need to include servlet API JARs?
Usually no. Tomcat provides the servlet and JSP APIs. Including them inside your application can create version conflicts.
Where should third-party libraries go?
Put runtime JARs in WEB-INF/lib. Do not place them in public directories unless there is a special reason and the application is designed for it.
Why does my app work locally but fail after upload?
The most common reasons are missing libraries, path differences, case sensitivity, Java version mismatch, or a build that was not packaged exactly like the local test environment.
Can I deploy a JSP app on a private JVM in Plesk?
Yes, if the hosting service provides a Java/Tomcat environment for your account. With a setup like My App Server, you can deploy JSP, servlet, and WAR-based applications through the panel, as long as the build matches the configured runtime.
Conclusion
A deployable JSP build should be complete, clean, and compatible with the target hosting environment. For Tomcat-based hosting, that means packaging JSP files, compiled classes, runtime libraries, configuration files, and public assets in the correct web application structure. In a managed hosting platform with Plesk and My App Server, careful packaging is especially important because the application runs inside a controlled Java and Tomcat setup.
If you prepare the build with the right structure and dependencies, deployment becomes much simpler: upload the WAR, map it to the selected Java service, and verify that the application starts without class loading or configuration errors. That is the most reliable way to deploy JSP applications on shared Java hosting without unnecessary downtime or troubleshooting.