If you are deploying a Java web application on Tomcat, the build must contain everything Tomcat needs to run the application, but nothing that should remain external unless you intentionally manage it that way. A deployable Tomcat build is usually a clean WAR file or a correctly structured exploded application directory with compiled classes, web resources, and any required runtime libraries packaged in the right place.
For hosted environments such as a managed Plesk setup with My App Server, this matters even more: the application should start cleanly under the selected Java version, use the configured Tomcat instance, and avoid conflicts with shared or preinstalled libraries. A well-prepared build reduces deployment errors, classpath issues, and version mismatches.
What a deployable Tomcat build should contain
A deployable Tomcat build should include only the files required to run the application on the target server. In practice, that usually means:
- Compiled application classes under
WEB-INF/classes - Application-specific JAR files under
WEB-INF/lib - Web content such as JSP pages, HTML files, CSS, JavaScript, and images
- Deployment descriptor such as
WEB-INF/web.xmlwhen your app requires it - Configuration files that your application reads at runtime
If you are creating a WAR build, the package must follow the standard Java web application structure. If you are deploying an exploded directory in Plesk or another control panel, the same structure still applies.
Standard Tomcat build structure
WAR package layout
The most common deployable artifact for Tomcat is a WAR file. A typical WAR contains the following structure:
index.jspor other public web files at the root levelWEB-INF/directoryWEB-INF/classes/for compiled.classfilesWEB-INF/lib/for dependency JARsWEB-INF/web.xmlif used by the application- Optional framework resources, templates, and static assets
Tomcat does not deploy source files such as .java files directly. The build should contain compiled output and runtime resources only.
Exploded deployment directory
Some hosting platforms and control panels allow you to deploy an exploded application instead of a WAR file. In that case, the structure should still mirror a standard web application layout. This can be useful when you want to upload files manually, replace a single JSP, or troubleshoot a deployment issue more easily.
For a managed Java hosting setup, an exploded deployment can be practical when the application is small or when the deployment process is handled through Plesk and My App Server. However, the structure must remain consistent and the files should be placed in the correct directories.
Files that should be included in the build
1. Compiled classes
Your application’s compiled Java classes belong in WEB-INF/classes. These are the output of your build process, typically generated from your source code during Maven, Gradle, or Ant packaging.
Examples of content that should be present:
- Servlet classes
- Filter classes
- Controller classes
- Service and helper classes
- Custom application-specific Java classes
Do not upload raw source code as the only implementation unless you are intentionally using a build process that compiles it on the server, which is not the usual approach for a reliable Tomcat deployment.
2. Runtime dependencies
All libraries required by your application at runtime should be packaged in WEB-INF/lib, unless they are already provided by the server and you have a deliberate reason to use the shared version.
Typical runtime dependencies include:
- Framework JARs
- Database drivers, if they are not provided by the platform
- JSON libraries
- Logging libraries
- Utility libraries used by your code
In a hosted Tomcat environment, packaging dependencies with the application is often the safest choice because it keeps the build self-contained and reduces classpath surprises.
3. Web resources
Static and presentation-layer files should be included in the application package. This includes:
- JSP files
- HTML pages
- CSS files
- JavaScript files
- Images and fonts
- Templates or view fragments used by your framework
These files are usually placed at the web root or in clearly defined resource directories. If your framework expects certain paths, keep the build layout aligned with those expectations.
4. Deployment descriptor and configuration
Some applications require WEB-INF/web.xml to define servlets, filters, listeners, welcome files, and security settings. Modern applications may use annotations instead, but the descriptor is still common and can be necessary depending on your stack.
You may also include:
- Application properties files
- Environment-specific configuration templates
- XML configuration files
- Message bundles for localization
When deploying on a managed hosting platform, consider which settings should be bundled in the build and which should be externalized for easier maintenance.
What should not be included in a deployable build
A clean Tomcat build should not contain development-only files or unnecessary artifacts. Keeping the package lean improves deployment reliability and reduces confusion.
- Source folders unless your workflow specifically needs them
- IDE metadata such as Eclipse, IntelliJ IDEA, or NetBeans project files
- Build tool caches and intermediate output
- Test classes and test resources
- Temporary files created by your editor or operating system
- Duplicate libraries that can cause classpath conflicts
Including unnecessary files increases package size and can make troubleshooting harder. In Tomcat hosting, a smaller and cleaner build is usually easier to deploy and maintain.
How to prepare a build for Tomcat hosting
Step 1: Compile the application
First, compile the Java sources with the same Java version that your target Tomcat environment uses. This is especially important in a hosting platform where the Java runtime can be selected or changed through the control panel.
Check that the bytecode level matches the configured JVM. If your application is compiled for a newer release than the server supports, the application may fail during startup.
Step 2: Package dependencies correctly
Review every dependency and decide whether it belongs inside the application package. For most hosted Tomcat deployments, application libraries should live in WEB-INF/lib.
Be careful with libraries that can exist in multiple versions across different applications. If your application depends on a specific version, package it with the build instead of assuming a shared server library will match.
Step 3: Verify the web application structure
Before deployment, inspect the archive to make sure the folder structure is correct. A common issue is accidental nesting, such as a WAR containing another top-level folder instead of placing files directly in the application root.
For example, the build should not look like this:
myapp.war/myapp/WEB-INF/classes
It should look like this:
myapp.war/WEB-INF/classes
Step 4: Confirm configuration files and environment values
Check that all required configuration files are present and that the app can read them in the hosting environment. If your application uses environment-specific settings such as database URLs, mail server details, or API keys, make sure these are provided securely and consistently with the deployment method.
In a Plesk-based setup with My App Server, some settings may be managed at the service level or through application configuration. Keep the build independent from machine-specific paths whenever possible.
Step 5: Test locally before uploading
Run the build locally in a Tomcat instance that matches the target version as closely as possible. Confirm that:
- The application starts without missing class errors
- JSP pages compile correctly
- Static resources load properly
- Database connections work as expected
- No library conflicts appear in the logs
If you are deploying to managed Java hosting, local verification saves time and reduces the number of failed uploads or restarts.
Tomcat-specific packaging best practices
Keep the application self-contained
A deployable Tomcat build should generally be self-contained. That means it should include the libraries and code needed to run, rather than relying on hidden server state. This is especially useful when you deploy a private JVM or dedicated Tomcat instance through a hosting control panel.
Avoid conflicting library versions
One of the most common causes of deployment failure is a classpath conflict. If the same library exists in both the application and the server, the application may behave unpredictably depending on the class loading order.
To reduce risk:
- Package the exact runtime version you need
- Remove unused JAR files
- Do not copy libraries into multiple locations without a reason
- Check for duplicate classes across JARs
Use the correct Java version
The build must be compatible with the Java version selected for the Tomcat instance. In a hosting platform that supports multiple Java versions, this is a key deployment requirement. If you compile on a newer JDK but deploy on an older runtime, the application may fail to load.
Match the compiler target and source compatibility settings to the runtime you plan to use.
Keep logs and temp files out of the build
Logs, temporary files, and generated caches should remain outside the deployable package. They belong on the server filesystem, not inside the application archive. This keeps the deployment clean and helps Tomcat manage runtime data properly.
Common mistakes in deployable Tomcat builds
- Missing JARs in
WEB-INF/lib - Wrong directory structure inside the WAR
- Compiled for the wrong Java version
- Including source files instead of compiled classes
- Packaging test libraries by mistake
- Using conflicting versions of the same dependency
- Leaving out web.xml when the application still depends on it
- Hardcoding server paths that do not exist in the hosting environment
These mistakes often show up as startup failures, 404 errors, missing classes, or JSP compilation problems after deployment.
How this relates to Plesk and My App Server
In a hosting environment with My App Server, the goal is to deploy an application that can be managed through the control panel with minimal manual correction. A properly prepared Tomcat build supports that goal by making deployment predictable.
This is particularly helpful when:
- You want to install a Tomcat version from the available options
- You need to upload a WAR file or an exploded build
- You want to run your own application under a private JVM
- You need to switch Java versions while keeping the application structure stable
- You want to manage a small or medium Java web application without a full enterprise application server setup
If the build is correct, the service can usually be started, stopped, and monitored more easily from the hosting control panel. If the build is incomplete or contains conflicting files, troubleshooting becomes slower and more complex.
Practical deployment checklist
- Compile the application successfully
- Match the Java version to the target Tomcat runtime
- Package compiled classes into
WEB-INF/classes - Place application JARs into
WEB-INF/lib - Include JSP, HTML, CSS, JavaScript, and image resources
- Add
WEB-INF/web.xmlif the app requires it - Remove source, test, and IDE files from the final package
- Check for duplicate libraries and version conflicts
- Test the WAR locally before upload
- Verify logs after deployment in the hosting panel
FAQ
Should a Tomcat deployable build include source code?
Usually no. A deployable Tomcat build should include compiled classes and runtime resources, not raw source code. The source belongs in your version control system and build pipeline, not in the final deployment package.
Do all applications need web.xml?
No. Many modern applications use annotations and framework-based configuration instead of web.xml. However, some applications still depend on it, so check your framework and servlet setup before packaging.
Should libraries be bundled in the WAR or installed on the server?
For most hosted Tomcat deployments, bundling application-specific libraries in the WAR is the safest approach. Server-wide libraries should only be used when you intentionally want shared dependencies and understand the compatibility impact.
Can I deploy an exploded Tomcat application in Plesk?
Yes, if the hosting environment supports it. An exploded deployment can be useful for manual updates or troubleshooting. The directory structure must still follow standard Tomcat conventions.
What causes Tomcat deployment errors most often?
Common causes include missing dependencies, incorrect packaging, wrong Java version, and library conflicts. Startup logs usually provide clues about the specific file or class that is missing.
How do I know if my build is ready for managed hosting?
If the application compiles cleanly, runs locally on a matching Tomcat and Java version, and the final WAR contains only the required runtime files, it is usually ready for upload and deployment in a managed hosting environment.
Conclusion
A deployable Tomcat build should be complete, clean, and aligned with the target runtime. Include compiled classes, required libraries, web resources, and any necessary configuration files. Exclude source files, test artifacts, and unnecessary project metadata. In a managed Java hosting environment such as My App Server in Plesk, following these rules helps ensure smoother uploads, faster deployment, and fewer runtime issues.
When the build structure is correct, Tomcat can load the application predictably, your Java version remains compatible, and the hosting control panel can manage the service more effectively. That is the foundation of reliable JSP, servlet, and Tomcat hosting.