If a Java application stops loading, returns a blank page, or shows a public error such as 404 or 500, the cause is usually easier to identify than it first appears. In a hosted Java environment, the problem may be related to the web application itself, the Tomcat configuration, the deployed WAR file, the Java version, file permissions, or the way Apache forwards requests to the application server.
When you use a hosting control panel such as Plesk with a Java hosting extension like My App Server, you can check many of these points directly from the panel. This article explains how to trace the source of a broken Java application step by step, with a focus on practical checks for shared hosting, Tomcat hosting, JSP hosting, servlet hosting, and private JVM setups.
What “broken” usually means in a Java hosting environment
A Java application can fail in different ways, and the visible symptom often points to a specific layer of the stack.
- 404 Not Found — the request reaches the web server, but the application or path is missing, not deployed, or mapped incorrectly.
- 500 Internal Server Error — the application was found, but it failed while starting or processing a request.
- Blank page or partial content — the app may be loading resources incorrectly, failing in JavaScript, or throwing an error behind the scenes.
- Application not starting — Tomcat or the private JVM may be stopped, misconfigured, or blocked by an error in startup scripts or environment settings.
- Redirect loop or timeout — the web server, proxy, or application may disagree on paths, ports, or context configuration.
In a managed hosting setup, it is best to investigate from the outside in: first confirm that the service is running, then check the deployment, then inspect logs, and finally verify application-specific code or configuration.
Check whether the Java service is running
The first step is to verify that the Java service itself is active. In a Plesk-based Java hosting setup, the My App Server extension typically provides service status and basic control options for the Tomcat instance or private JVM.
What to look for in the control panel
- Service status: running, stopped, or starting
- Selected Java version
- Configured application server type, such as Tomcat
- Allocated paths for the app, logs, and runtime files
- Recent start or stop events
If the service is stopped, restart it from the control panel and refresh the site. If the service starts and then stops again, the reason is usually visible in the application server logs.
Why this matters
A public 500 error can appear even when the web server is working correctly, simply because Tomcat never started or crashed during boot. In a private JVM setup, the Java process must be healthy before any servlet or JSP application can respond.
Confirm that the application is deployed correctly
A very common cause of broken Java apps is an incomplete or incorrect deployment. The application may be missing its WAR file, unpacked files, or the expected context path.
Deployment checks
- Is the WAR file uploaded to the correct application directory?
- Was the deployment completed successfully?
- Is the application unpacked if your setup expects exploded files?
- Does the context path match the URL you are trying to access?
- Has the application been overwritten by a partial upload or failed update?
For example, if your application is deployed under /shop but you visit the site root, the request may return 404 even though the app is installed correctly. Likewise, if the app is deployed to a different context after a reinstall, old bookmarks and links may stop working.
Typical deployment-related symptoms
- 404 on the root URL, but the application exists under another path
- 500 immediately after deployment
- Old version still appears after upload
- Static files load, but servlets do not respond
Check the application and Tomcat logs
Logs are the fastest way to find the real cause of a broken Java application. In hosted environments, the web server error log, Tomcat logs, and application logs often reveal the exact class, line, or resource causing the failure.
Where to look
- Tomcat catalina logs for startup and runtime errors
- Application logs if the app writes its own log files
- Apache error log for proxy or rewrite issues
- Access logs for request paths, status codes, and repeated failures
Common log messages and what they usually mean
- ClassNotFoundException — a required library is missing from the application package or classpath.
- NoSuchMethodError — incompatible library versions are being used together.
- UnsupportedClassVersionError — the app was compiled with a newer Java version than the one currently selected.
- Port already in use — Tomcat or another service is trying to bind to a port that is occupied.
- Permission denied — the application cannot read, write, or execute a needed file or directory.
- Context path already in use — two deployments or configurations are conflicting.
If your hosting panel gives you access to logs, review the last entries from the time the issue started. If the app fails only for one route, inspect the access log to confirm whether the request reaches Tomcat or is blocked earlier by Apache or a rewrite rule.
Verify the Java version and application compatibility
Java applications are often sensitive to the Java runtime version. A build compiled for a newer JDK may not run on an older JVM. Some apps also depend on framework libraries that behave differently between major Java versions.
What to verify
- The active Java version in the control panel
- The version required by the application
- Any recent change to the selected Java runtime
- Whether the app was built for Java 8, Java 11, Java 17, or another version
In My App Server, a key advantage is that you can select from several ready-to-install Java and Tomcat versions or configure a custom app server setup when needed. If the application stopped working after a runtime change, switching back to the previous compatible version is a logical test.
Signs of a Java version mismatch
- The app fails at startup with a class version error
- It worked after deployment, then broke after a Java update
- Only specific libraries fail to load
- Pages that depend on newer language features stop responding
Check file permissions and ownership
Broken Java apps often fail because the runtime cannot read configuration files, write session data, or access deployed resources. This is especially important in shared hosting environments, where permissions must be set correctly for the application to run under the account context.
Review these items
- Permissions on the application directory
- Write access for temporary folders and upload locations
- Permissions on configuration files such as properties or XML files
- Ownership after manual upload or migration
If the application starts but fails only when a user submits a form, uploads a file, or creates a session, the issue may be write access rather than a deployment problem.
Common examples
- The app cannot create a temporary file and returns 500
- Uploads fail because the target directory is not writable
- Session data cannot be stored, causing repeated logins or errors
Confirm Apache and Tomcat path mapping
In many hosting setups, Apache handles the public request and forwards it to Tomcat. If the mapping between Apache and the Java application is incorrect, the site may return 404 even though the app itself is running.
Things to check
- Whether Apache is forwarding the request to the correct internal endpoint
- Whether the application context path matches the configured route
- Whether rewrite rules or proxy settings were changed recently
- Whether the app is listening on the expected port or connector
A wrong mapping can make the browser hit Apache successfully while Tomcat never receives the request. In that case, the error may look like a normal web server 404 rather than a Java application failure.
Signs of path or proxy problems
- Static files work, but dynamic pages do not
- The same URL works internally but not from the public site
- Only the main app path is broken, while assets return normally
- The error changes after a rewrite rule or proxy update
Inspect the web application configuration files
Many Java apps depend on configuration files such as web.xml, application properties, XML-based datasource settings, or environment-specific files. A small syntax error or wrong value can break the whole application.
Check for these common issues
- Broken XML syntax
- Wrong database host, username, or password
- Incorrect file paths after migration
- Missing environment variables
- Wrong application base URL
If the application starts but shows 500 errors only when a specific page or feature is accessed, the problem may be in a configuration value used by that feature. A database connection error is one of the most common examples.
Example scenario
If a JSP application loads its home page but fails when reading data from the database, check whether the datasource settings still point to the correct database server and schema. A valid deployment can still fail if the configuration contains old credentials or a moved database endpoint.
Check application dependencies and packaged libraries
Java web applications usually depend on JAR files bundled with the app or provided by the runtime. A broken dependency is a frequent source of startup errors and public 500 pages.
What to review
- Missing JAR files in WEB-INF/lib
- Duplicate libraries with different versions
- Incompatible framework versions
- Libraries copied manually during migration
When a dependency is missing, the app may compile locally but fail on the server. If the problem started after a deploy or upgrade, compare the current package with the previous working release.
Rule out resource limits
In shared Java hosting, an application can also fail because it reaches a limit. This may be memory-related, process-related, or connected to the allowed service usage in your hosting plan.
Check for limit-related symptoms
- The app starts and then stops under load
- Pages become slow before returning 500
- Large file uploads fail
- Repeated restarts occur after deployment
If your hosting account has limits on memory, CPU, or service usage, a Java application that is too heavy for its current configuration may fail to start or remain stable. Review the service limits and compare them with the application’s real needs. A small to medium Tomcat app may run comfortably, but it still needs enough heap, enough file access, and a sensible runtime configuration.
Use a simple isolation method to narrow the cause
If you are not sure whether the failure is caused by the app, the server, or the deployment, isolate the problem with a few controlled checks.
Step-by-step isolation process
- Open the application URL and note the exact error code or browser message.
- Restart the Java service from the control panel.
- Check whether the service starts cleanly or stops again.
- Review the latest Tomcat and Apache error log entries.
- Temporarily verify a known working test page or simple JSP if available.
- Compare the working deployment with the broken one.
- Check whether the issue started after a deploy, version change, or config edit.
This method helps separate platform issues from application issues. If a simple test page works but the full app fails, the problem is probably in the application package or configuration. If even a simple page does not load, the issue is more likely in service control, routing, or runtime setup.
How to troubleshoot specific error types
When you see 404
- Verify the context path and deployment location
- Check whether Apache is routing requests to the correct app server
- Confirm that the WAR was deployed successfully
- Look for typos in the URL or rewrite rules
When you see 500
- Check Tomcat logs for the exact exception
- Review Java version compatibility
- Confirm database and file permissions
- Inspect configuration files for invalid values
When the app loads partially
- Open the browser developer tools and check for failed resource requests
- Confirm that static assets are served from the expected paths
- Review application-side errors for broken templates or scripts
- Make sure the app base URL and asset URLs are correct
Practical checks in My App Server and Plesk
If you host Java applications with My App Server, the most useful first checks are usually available from the panel itself. That is especially helpful in shared hosting, where you do not need full server access to diagnose many common problems.
- Check the app server status before changing the deployment
- Verify which Java version is assigned to the service
- Restart the service after a configuration change
- Review log output after each change, not only at the end
- Use the panel to confirm the active Tomcat instance and application path
When a custom app server is used, make sure its startup parameters, ports, and file paths are consistent with the hosting account. If you uploaded a custom Tomcat version or JVM, re-check the exact configuration after any update.
Best practice after fixing the issue
Once the application works again, take a moment to reduce the chance of the same problem coming back.
- Keep a copy of the last known working deployment
- Document the Java version used by the application
- Save the active context path and service settings
- Track any manual changes made in the control panel
- Review logs after each update or restart
For managed hosting, a short rollback plan is often the fastest recovery method. If a new deployment breaks the app, restoring the previous package and configuration may be quicker than fixing the code under pressure.
FAQ
Why does my Java app return 404 even though Tomcat is running?
This usually means the service is active, but the application is not deployed at the expected path or Apache is not forwarding the request correctly. Check the context path, deployment status, and rewrite or proxy configuration.
Why am I getting 500 after uploading a new WAR file?
The new deployment may contain a missing library, a wrong Java version requirement, a configuration error, or a startup exception. Review the Tomcat logs immediately after deployment to see the exact cause.
Can a Java version change break an application?
Yes. If the app or one of its libraries was compiled for a newer Java release, an older runtime may fail to start it. Even a minor runtime change can expose compatibility issues in some applications.
What is the fastest way to find the cause of a broken app?
Check the service status, then open the latest logs. In most cases, the exact error message in Tomcat or Apache will point to the cause faster than browsing the application files manually.
Why does the app work on one page but fail on another?
That often indicates a feature-specific issue such as a missing database connection, a bad configuration value, or a problem loading a particular dependency or resource.
Should I restart Tomcat after every change?
If you changed Java settings, deployment files, or server configuration, a restart is often necessary for the change to take effect. For app-only updates, a redeploy may be enough, but always verify the result in the logs.
Conclusion
Finding the cause of a broken Java application is mostly a process of narrowing the problem layer by layer. Start with the service status, confirm the deployment, inspect logs, verify Java compatibility, and then check configuration, permissions, and routing. In a Plesk-based Java hosting environment with My App Server, these checks are practical to perform without deep server administration.
Most 404 and 500 issues come from a small set of causes: wrong path mapping, failed deployment, runtime mismatch, missing libraries, or configuration errors. By checking these areas in order, you can identify the source quickly and restore the application with minimal downtime.