Grails 5 WAR deployment: startup failure logs missing from the application log

Question

We are moving a Grails 5 application from the executable JAR to a WAR deployed on an external Tomcat, and a recent deployment failed silently: the application log showed only a wrapped BeanCreationException and then nothing, leaving us unsure where the root cause went.

In the executable JAR mode, the failure was visible in stdout with a full stack trace. Under Tomcat, the same failure appears to be split between catalina.out, the localhost log, and the app log, and the default stack trace filtering hides the underlying cause.

The uncertainty is whether this is a logging configuration issue (logback.groovy not loading, log levels), a container-vs-application log split, or a build issue (container dependency still compile-scoped instead of provided). We need a documented, version-appropriate way to get the full root cause when the WAR deployment fails.

For Grails 5, which configuration change reliably disables stack trace filtering and surfaces the original exception in the app log?
When deploying as a WAR, how should we separate container logs from application logs to confirm whether the failure is in Tomcat or the ApplicationContext?
Should we standardize on the embedded JAR for diagnostics, or is there a supported way to make WAR deployments equally observable?

Tasadduq Burney · Answer

Surface the Root Cause
To disable stack trace filtering and force the full causal chain of a BeanCreationException into your application logs, add the following property to your grails-app/conf/application.yml:
grails:
  full.stacktrace: true
If you are using a logback.groovy or logback-spring.xml configuration, ensure that the root logging level is set to INFO or DEBUG and that no custom filters are suppressing the org.springframework package during the startup phase.

Container vs. Application Log Split
When moving from an executable JAR to a WAR, the logging boundary shifts. In a JAR, the application owns the process and stdout. In a WAR, Tomcat owns the process, and the application is a guest.

Where to look for failures

catalina.out: Captures System.out and System.err. If the failure occurs during the initial class-loading phase or before the Spring ApplicationContext initializes the Logback appenders, the root cause will be here.
  localhost..log: Specifically captures Grails/Spring context initialization failures and servlet errors. If the app log is empty but the deployment failed, the BeanCreationException root cause is often trapped here.
  Application Log: Only captures events after the logging framework has successfully started.

Verification and Build Checks
To ensure the WAR is observable and stable, verify the following:

1. Dependency Scope
Ensure the embedded Tomcat starter is marked as provided. If these JARs exist inside WEB-INF/lib, they can conflict with the external Tomcat container, leading to silent failures or ClassCastException during startup.

2. Log Synchronization
Compare the timestamps across catalina.out, localhost.log, and your application log. If the application log ends abruptly while the container logs continue, the failure happened during the transition from the container's lifecycle to the Spring lifecycle.

3. Observability Parity
You do not need to revert to an executable JAR for diagnostics. By setting grails.full.stacktrace: true and explicitly monitoring the localhost log, you achieve the same observability as the JAR's stdout.

Diagnostic Request: Are you seeing any ClassNotFoundException or NoClassDefFoundError in catalina.out? This would confirm a dependency scope issue rather than a logging configuration problem.

Grails 5 WAR deployment: startup failure logs missing from the application log

1 answer

Surface the Root Cause

Container vs. Application Log Split

Where to look for failures

Verification and Build Checks

1. Dependency Scope

2. Log Synchronization

3. Observability Parity

Your perspective belongs here.

0 question comments