When a Java application deploys successfully on shared hosting, the build output usually matters more than the source code itself. Tomcat does not deploy a Maven project, a Gradle workspace, or an IDE folder structure. It deploys the output of your build: a WAR file, an exploded web application, or a set of compiled classes and resources packaged in the right format. If that output is incomplete, misnamed, or built for the wrong Java version, deployment may fail even when the application works perfectly on a local machine.
For Java hosting users in the UK using a control panel such as Plesk and a managed service like My App Server, the goal is simple: upload the correct build output, match it to the configured Java runtime, and let Apache Tomcat start the application without extra manual fixes. This article explains how build output affects deployment success, what to check before uploading, and how to avoid the most common packaging errors in Java hosting, Tomcat hosting, JSP hosting, and servlet hosting environments.
Why build output matters in Java hosting
In a hosting environment, the build output is the actual deliverable that the application server reads. Tomcat expects a structure it can unpack or run directly. If the archive or directory does not match what Tomcat needs, the application may fail during deployment, start with missing pages, or return errors such as 404, 500, or class-loading exceptions.
Typical build outputs for Java web applications include:
- WAR files for standard Java web apps
- Exploded WAR directories for manual deployment or troubleshooting
- JAR files for non-web Java applications, if supported in a specific hosting setup
- Compiled classes and resource files inside the expected web application structure
In My App Server, the application usually runs with its own private JVM and a chosen Apache Tomcat version. That means your build must fit the server version, the Java runtime version, and the deployment method offered in Plesk. A build that works in one environment may fail in another if it was compiled with a newer language level, packaged incorrectly, or depends on files that were not included in the final artifact.
What Tomcat expects from your build
Apache Tomcat is designed to deploy web applications in a specific format. For most hosting scenarios, the safest and most portable artifact is a standard WAR file created by Maven, Gradle, or another build tool.
Expected WAR structure
A typical WAR file contains:
WEB-INF/for configuration, classes, and librariesWEB-INF/classes/for compiled application classesWEB-INF/lib/for dependent JAR files- Static resources such as JSP, HTML, CSS, JavaScript, and images
If these elements are missing or placed in the wrong location, Tomcat may deploy the archive but still fail when the application is accessed. For example, a JSP file stored outside the correct web root may not be reachable, or a required library may not be loaded.
Common build output formats and their use
- WAR - best for deploying a complete web application
- Exploded directory - useful for debugging and manual review before packaging
- JAR - typically used for standalone Java apps, not standard Tomcat web deployments
On a managed hosting platform, a WAR file is usually the cleanest option because it is easier to upload, replace, and roll back through the control panel.
How build output affects deployment success
Several deployment problems can be traced directly to the build output rather than the server itself. Understanding these problems helps you troubleshoot faster and avoid repeated upload cycles.
1. Wrong Java version at compile time
If your project is compiled with a Java version newer than the runtime configured in My App Server, the application may fail to start with class version errors. This is one of the most common causes of deployment failure.
Example:
- You compile with Java 21 locally
- The hosting service runs Java 17 for that app server instance
- Tomcat cannot load the compiled classes
To prevent this, compile against the same Java version or a compatible lower version that matches the runtime selected in Plesk.
2. Missing dependencies in the final package
Build tools may resolve dependencies locally but exclude them from the final WAR if the packaging is misconfigured. The application then starts, but fails when a class is requested at runtime.
Typical symptoms include:
ClassNotFoundExceptionNoClassDefFoundError- Application loads partially, then returns HTTP 500
Check whether the required JARs are included in WEB-INF/lib and that test-only libraries are not mistakenly relied upon in production.
3. Incorrect web application structure
If the build output is not structured like a web application, Tomcat may not know where the application starts. A common issue is placing files at the root of the archive instead of inside the web content structure expected by the server.
Make sure that:
- Compiled classes are in the correct classes folder
- Libraries are inside the library folder
- JSP and static files are in the web root or mapped correctly
- Deployment descriptors are placed where Tomcat can read them
4. File naming and path conflicts
In control panel deployments, the application name, archive name, and context path can influence how Tomcat exposes the app. If the build output is named inconsistently or includes unexpected nested folders, deployment can succeed but the site may open on the wrong path or fail to load resources.
Keep the archive name simple and avoid extra directory nesting inside the upload. A clean WAR file is easier to manage in Plesk and reduces context path confusion.
5. Build output contains environment-specific files
Sometimes a local build accidentally includes machine-specific paths, IDE metadata, or development-only configuration. These items are not only unnecessary, they may also break deployment when the file layout changes on the hosting server.
Examples to exclude from production output:
- IDE project files
- Local absolute paths
- Test fixtures
- Debug-only properties
Best practices for packaging Java apps for My App Server
In a hosting environment with private JVM control and Tomcat management through Plesk, the most reliable deployments are the ones built with a repeatable packaging process. The following practices improve compatibility and reduce manual fixes.
Use a standard build tool
Maven and Gradle are the most common choices because they produce predictable outputs and make it easier to control dependency packaging. A standard build tool also helps ensure the output can be recreated after every code change.
Recommended checks:
- Confirm the build produces a WAR file for web applications
- Verify the artifact includes all runtime dependencies
- Set the correct Java source and target compatibility
- Keep resource files in the expected locations
Match build settings to the hosting Java runtime
Before uploading to My App Server, confirm which Java version is selected for the application instance. Then set your build tool to compile for that version. This avoids bytecode compatibility issues and reduces the chance of deployment failure.
Good practice is to align:
- Local development JDK
- Build tool source level
- Target bytecode version
- Server runtime in Plesk
Package only what the server needs
A hosting-friendly build output should be lean. Avoid bundling unnecessary artifacts that make uploads slower and troubleshooting harder. Keep the deployment package focused on runtime files only.
For example:
- Include production dependencies
- Exclude test libraries
- Exclude source folders unless specifically needed
- Exclude temporary build files
Test the artifact before upload
Before deploying to the hosting account, test the final WAR locally or in a staging environment. This helps confirm that the application starts from the packaged artifact rather than from the IDE project.
Useful checks include:
- Does the WAR open and unpack correctly?
- Does the app start from the packaged output?
- Are all JSP pages reachable?
- Are static assets loading without broken paths?
Uploading build output in Plesk
With a managed hosting control panel, deployment is often easier when the artifact is prepared correctly in advance. My App Server is designed to make Java hosting more practical for small and medium web applications by giving you a controlled Tomcat and private JVM inside the hosting account.
Typical deployment flow
- Build the application into a WAR file
- Check that the Java version matches the server runtime
- Upload the WAR through the control panel or file manager
- Deploy it to the configured My App Server instance
- Restart or reload the service if required
Depending on the application and version, you may be able to install one of the ready-made Java or Tomcat versions with a button, or upload and configure a custom version manually. In both cases, build output compatibility remains essential.
When exploded deployment is useful
Exploded deployment can help during troubleshooting because you can inspect the file structure directly. However, for regular hosting use, a WAR file is usually easier to manage. It is cleaner for backups, simpler for rollbacks, and less likely to accumulate incorrect manual edits.
Common deployment errors caused by bad build output
When a deployment fails, the error shown in Tomcat or the application logs often reflects a packaging issue. Here are some common examples and what they usually mean.
HTTP 404 after deployment
If Tomcat deploys the application but you still get 404 errors, the build output may not contain the expected page at the expected path. This can happen when the web root is wrong or when the context path does not match the archive structure.
HTTP 500 on first request
A 500 error after deployment often points to missing classes, unresolved dependencies, or a runtime mismatch. It can also happen when JSP compilation fails due to missing tag libraries or incorrect package placement.
Startup failure in the server log
If Tomcat refuses to start the app, check for:
- Unsupported Java bytecode version
- Missing configuration files
- Invalid deployment descriptors
- Broken references to libraries or resources
App starts locally but not on hosting
This usually means the local build process is relying on something the hosting server does not have. The most common causes are environment-specific variables, local file paths, or a Java version mismatch.
Practical checklist before deployment
Use this checklist before uploading a Java build output to your hosting account:
- Confirm the artifact is a WAR file if the app is web-based
- Make sure the Java version matches the server runtime
- Verify all runtime dependencies are included
- Check that JSP, servlet, and static files are in the right place
- Remove IDE files, test files, and development-only settings
- Test the packaged artifact locally before upload
- Use simple archive names to avoid context path confusion
- Review Tomcat logs after deployment
For users of My App Server, this checklist is especially useful because the server setup is intentionally practical and controlled. You get access to a dedicated Java runtime within the hosting account, but the deployment still depends on the package quality.
How to troubleshoot build output problems
If deployment fails, isolate the issue by checking the output from the outside in. Start with the package, then the runtime, then the server logs.
Step 1: Inspect the archive
Open the WAR file and verify its structure. Look for missing folders, nested folders created by mistake, or files that should not be there.
Step 2: Compare build and runtime versions
Check the Java version used to compile the application and compare it with the runtime configured in the hosting panel. This step solves many deployment failures quickly.
Step 3: Review dependency packaging
Confirm that the application does not rely on libraries that were only present in the IDE or in a test environment.
Step 4: Read the Tomcat logs
Logs usually reveal whether the issue is a missing class, a configuration problem, a failed JSP compilation, or a path error. In managed hosting, logs are one of the most valuable troubleshooting tools after the build artifact itself.
Step 5: Redeploy a clean build
If in doubt, clean the project, rebuild from scratch, and upload a fresh artifact. This helps eliminate stale files that may have been left behind by an incremental build.
Why this matters for UK hosting customers
For UK hosting customers, reliability and quick turnaround are often more important than complex platform features. A well-packaged Java build saves time during deployment, reduces support requests, and makes it easier to manage applications through a familiar control panel workflow.
That is one reason a setup like My App Server is practical for small and medium Java applications: you can select or configure a Java runtime, manage a private JVM, deploy a WAR, and control the service without needing a heavy enterprise platform. The better your build output, the smoother the deployment experience will be.
FAQ
What is the best build output for Tomcat deployment?
For most Java web applications, a WAR file is the best choice. It is standard, portable, and easy to deploy in Tomcat through a control panel.
Why does my app work locally but fail on hosting?
Usually because the hosting Java version differs from your local setup, or because the final packaged artifact is missing dependencies or files.
Can I deploy a JAR file to My App Server?
My App Server is designed primarily for Java web applications, Tomcat, JSP, and servlet hosting. A JAR may be suitable only in specific cases, depending on how the service is configured.
Do I need an exploded directory or a WAR file?
A WAR file is usually recommended for regular deployments. An exploded directory can be useful for debugging, but it is less convenient for everyday hosting use.
How do I know if my build uses the right Java version?
Check the compiler source and target settings in your build tool, then compare them with the Java runtime selected for the application in the hosting control panel.
What should I do if Tomcat shows class loading errors?
First confirm that the missing class is included in the final package. If it is, check whether the application was compiled for a newer Java version than the server supports.
Can I upload files manually instead of using a build tool?
Yes, but manual packaging increases the risk of missing files or incorrect folder structure. A build tool is usually safer and more repeatable.
Conclusion
Deployment success in Java hosting depends heavily on build output quality. A correctly packaged WAR, compiled for the right Java version and structured for Tomcat, is far more likely to deploy cleanly than a loosely prepared project folder. In a Plesk-based setup like My App Server, good build output makes the difference between a smooth upload and repeated troubleshooting.
If you keep the packaging standard, match the runtime version, include the right dependencies, and test the final artifact before deployment, you will avoid most of the common issues seen in Java hosting, Tomcat hosting, and JSP hosting environments. For small and medium applications, that approach is usually the most reliable way to achieve consistent deployment results.