When you prepare a JSP application for deployment, the build should contain everything the web container needs to run it cleanly, but nothing unnecessary that can cause conflicts or increase upload size. In a hosting environment with Plesk and a Tomcat-based setup such as My App Server, this usually means packaging your application so the final artifact is predictable, portable, and ready to run as a WAR or as an extracted web application.
If you are deploying on a shared hosting account with a private JVM or a managed Tomcat instance, the most reliable build is one that includes compiled classes, JSPs, static resources, configuration files, and only the libraries your application actually needs. The aim is to make the deployment simple: upload the build, point Tomcat to it, and let the container handle the runtime.
What a deployable JSP build should contain
A deployable JSP build normally contains the application code, web content, and runtime metadata that Tomcat uses to start the web app. In most cases, the correct output is a WAR file, but some hosting setups also allow an unpacked web application directory.
The essential parts are:
- JSP files — the pages that will be compiled by the container at runtime.
- Compiled Java classes — servlet classes, helper classes, controllers, filters, listeners, and other application logic.
- Library JAR files — third-party dependencies and any application-specific JARs not provided by the platform.
- Static assets — CSS, JavaScript, images, fonts, and downloadable files.
- Deployment descriptor and metadata — such as
web.xmlif your application uses it. - Configuration resources — property files, XML files, logging configuration, or environment-specific settings that your app expects.
In a Tomcat hosting context, this content should be placed in the structure the container expects, so that the build can be deployed without manual cleanup or guessing which files belong where.
Recommended WAR structure for JSP hosting
The most common and portable format is a WAR archive. A standard WAR build typically includes the following structure:
index.jspor other JSP entry pagesWEB-INF/WEB-INF/classes/for compiled classes and resource bundlesWEB-INF/lib/for dependency JAR filesWEB-INF/web.xmlwhen needed- Static content outside
WEB-INF, for examplecss/,js/,images/
This layout works well for JSP hosting and servlet hosting because Tomcat can load classes and libraries from the correct locations while serving public assets directly.
What belongs in WEB-INF/classes
WEB-INF/classes is the place for compiled application classes and non-JAR resources that must be on the application classpath. This may include:
- Servlet classes
- Filter classes
- Listener classes
- Helper or service classes
- Properties files and XML resources loaded by the application
Keep the package structure intact. For example, if your source package is com.example.app, the compiled class files should end up in the matching directory tree under WEB-INF/classes.
What belongs in WEB-INF/lib
WEB-INF/lib is where you place dependency JARs required by the web application. This usually includes libraries such as JSON processors, logging libraries, database drivers, template engines, validation libraries, and other frameworks your app depends on.
Only include the JARs that your application actually needs. Avoid copying every library from your development machine. Extra or duplicate JARs can lead to class loading conflicts, version mismatches, and harder troubleshooting during deployment.
What should stay outside WEB-INF
Files outside WEB-INF are normally public and accessible through the browser. This is where you place:
- JSP pages that should be directly reachable
- CSS, JavaScript, and images
- Public downloads or frontend assets
Do not place sensitive configuration, source code, private keys, or server-side-only files in public directories. Anything that should not be exposed must be inside WEB-INF or managed outside the deployable artifact.
Files you should include before deployment
Before uploading to a hosting platform or using a Plesk control panel deployment workflow, check that the build includes the following items.
Compiled Java code
Your build should include compiled .class files, not source .java files. JSP pages are compiled by the container, but Java support code must already be compiled unless your deployment process performs the compilation for you.
If your build is created from a Maven, Gradle, or Ant process, verify that the output is being placed into the expected WAR structure and that no source folders are accidentally packaged.
JSP pages and tag files
Make sure all JSP pages, tag files, and custom tag-related resources are present. If your application uses JSP fragments or includes, confirm that the paths are correct after packaging.
For example, if your pages include shared header and footer files, those files must also be in the build and accessible using the same relative or absolute paths that work in the container.
Static content
Static files are part of the user experience and should be present in every deployable build. This includes:
- Stylesheets
- Client-side scripts
- Images and icons
- Fonts
- Documents and downloadable assets
Missing static files can make the application appear broken even when the server-side code is working correctly.
Configuration files
Include any application configuration files required at startup. Depending on your project, this may involve:
web.xml- Spring or framework configuration files
- Database connection settings used by the app
- Logging configuration such as
log4j2.xmlorlogback.xml - Message bundles for localisation
For hosting environments, it is best to keep environment-specific values out of the application build when possible and use external configuration or secure deployment settings if your platform supports them.
Dependency JARs
Your build should include the dependency JARs that are not provided by the server. This is especially important in Java hosting environments where the application is expected to run in its own isolated classpath inside Tomcat.
However, do not duplicate libraries that are already provided by the runtime unless your application specifically requires a bundled version. Duplicates can cause unpredictable behavior.
What should not be included in the build
A clean deployable JSP build is not just about what to include, but also about what to leave out. Removing unnecessary files helps reduce upload size and avoids confusion during deployment.
- Source folders such as
src/ - IDE metadata from Eclipse, IntelliJ IDEA, or NetBeans
- Build scripts that are not needed at runtime
- Local-only environment files
- Temporary files, logs, and caches
- Test resources that are not required in production
- Duplicate or unused JAR files
If you package too much into the WAR, deployment can become slower and troubleshooting can become harder. In a managed hosting setup, a lean package is usually the best choice.
Build checklist for Tomcat and Plesk deployment
Use this checklist before you deploy to a My App Server environment or any Tomcat-based hosting account.
- Compile the application against the correct Java version.
- Confirm that the build produces a WAR or an equivalent deployable directory.
- Verify that all classes are under
WEB-INF/classes. - Verify that dependency JARs are under
WEB-INF/lib. - Check that JSP pages are included in the correct web root locations.
- Make sure static assets are present and path references are correct.
- Review configuration files for hardcoded local paths or machine-specific settings.
- Remove source code, test files, and development-only artifacts.
- Confirm that no duplicate library versions are bundled by mistake.
- Test the WAR locally in a matching Tomcat version before uploading.
If your hosting account uses Plesk and My App Server, a clean WAR build makes deployment much smoother because the container can start the application without manual repair work.
How Java version and Tomcat version affect the build
The deployable build must be compatible with the Java runtime and Tomcat version available in your hosting environment. A JSP application compiled for a newer bytecode level than the server supports will not start correctly.
Check the following:
- The Java source and target compatibility in your build tool
- The servlet API version your application expects
- The Tomcat version running in your hosting account
- Whether your app depends on libraries that require a newer JVM
When using a hosted Tomcat instance or a private JVM, align your build with the runtime version configured in the control panel. This reduces deployment failures caused by class version errors or missing APIs.
Practical packaging examples
Simple JSP site
A small JSP site may only need:
- JSP pages
- One or two helper classes
- CSS and image files
- A small number of dependency JARs
This kind of application is a good fit for JSP hosting or lightweight Tomcat hosting because the build is small and easy to redeploy.
Servlet-based application
If your application uses servlets, filters, and listeners, the build should additionally include:
- Servlet classes
- Filter mappings
- Listener registrations
- Any framework classes needed for request handling
These components should be compiled and packaged in the correct directory structure so Tomcat can load them on startup.
Framework-based application
For applications built with a framework, the build may contain more configuration and more dependency JARs. The key principle remains the same: include only the runtime dependencies and configuration files needed by the deployed application, and keep development tools out of the final package.
Common deployment issues caused by missing build content
Many JSP deployment problems are caused by incomplete builds rather than server faults. Typical symptoms include:
- 404 errors for missing JSP or static files
- ClassNotFoundException for missing compiled classes or libraries
- NoClassDefFoundError when a dependency is not packaged correctly
- JSP compilation errors due to missing tag libraries or includes
- Application startup failures because configuration files are absent
When you see one of these issues, inspect the WAR contents first. In many cases, the fix is to correct the packaging step rather than adjust the server.
Best practices for hosting-friendly JSP builds
For managed hosting and control panel environments, these practices make deployment easier and safer:
- Build a repeatable WAR from source control.
- Keep runtime configuration separate from code where possible.
- Use clear versioning for dependency JARs.
- Test locally with the same Java and Tomcat version used in hosting.
- Validate the WAR structure before upload.
- Keep the deployment package minimal and deterministic.
If your hosting platform provides a dedicated application service such as My App Server, use its control panel features to manage the application lifecycle after the build has been uploaded. A well-structured package makes start, stop, restart, and redeploy operations more reliable.
FAQ
Should a deployable JSP build include source code?
No. In most cases, you should not include source .java files in the final deployable package. Include compiled .class files instead.
Is a WAR file better than uploading loose files?
For most JSP and Tomcat deployments, yes. A WAR file provides a standard structure and reduces the chance of missing files during upload. Some environments also support unpacked deployments, but WAR is usually easier to manage.
Do I need to include Tomcat libraries in my application build?
No, not normally. Do not bundle the container’s own libraries unless your application specifically requires a separate version and your deployment process is designed for that. In most hosting scenarios, the runtime provides the servlet container libraries.
Where should database drivers go?
If your application needs a JDBC driver and it is not already available in the runtime, place the driver JAR in WEB-INF/lib. If your hosting setup provides shared drivers or a separate classpath mechanism, follow the platform’s deployment guidance.
Why does my JSP page work locally but fail after upload?
This often happens when the local build includes files that are missing from the deployed WAR, or when the application depends on local paths, a different Java version, or a library that was not packaged correctly. Compare the local and deployed build contents carefully.
Can I use the same build for multiple Tomcat versions?
Sometimes, but only if the application is compiled for a compatible Java level and does not depend on version-specific APIs. Always test against the target runtime before deploying to production.
Conclusion
A deployable JSP build should contain the compiled application, JSP files, required libraries, static assets, and only the configuration needed for runtime execution. For hosting environments based on Plesk and Tomcat, the best result is usually a clean WAR file that matches the Java and container version available in the service.
When the build is packaged correctly, deployment becomes faster, troubleshooting becomes simpler, and your JSP or servlet application is more likely to run consistently in a managed hosting environment. The most important rule is to include everything the application needs at runtime, while leaving out source files, test artifacts, and unnecessary dependencies.