WAR Deployment in Wildfly 32 breaks container logging

[philippn]

Hi there,

I ran into this problem recently, the logging system generally seems to cause problems with recent version of Wildfly.

Steps to reproduce:

1. Go to initializer and configure a Spring MVC webapp with WAR deployment mode. I used Spring Boot 3.3.4.
2. Add some minimal controller logging out something
3. Download Wildfly (I used 32.0.1.Final)
4. Build app and deploy

Now there are actually two issues: When you first attempt to deploy it, the deployment will fail with this error:

deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."demo-0.0.1-SNAPSHOT.war".undertow-deployment: java.lang.RuntimeException: java.lang.IllegalArgumentException: LoggerFactory is not a Logback LoggerContext but Logback is on the classpath. Either remove Logback or the competing implementation (class org.slf4j.impl.Slf4jLoggerFactory loaded from jar:file:/C:/Users/nanz0phi/Downloads/wildfly-32.0.1.Final/modules/system/layers/base/org/slf4j/impl/main/slf4j-jboss-logmanager-2.0.1.Final.jar!/). If you are using WebLogic you will need to add 'org.slf4j' to prefer-application-packages in WEB-INF/weblogic.xml: org.slf4j.impl.Slf4jLoggerFactory
    at org.wildfly.extension.undertow@32.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:73)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)

Indeed, there is a logback.jar in the WAR file, but you can remedate that using

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-logging</artifactId>
    <scope>provided</scope>
</dependency>

Now, the WAR file will deploy.

But: the last message you will see on the console is this:

07:54:15,570 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 104) 2 Spring WebApplicationInitializers detected on classpath
Handler java.util.logging.ConsoleHandler is not defined

After that, no more log message will be seen on the console. What is even more worrysome is that this also breaks logging of other apps deployed in the same wildfly.

A work-around for this problem is to set the system property org.springframework.boot.logging.LoggingSystem to none, as per StackOverflow.

In a nutshell:

• Spring initialz should add spring-boot-starter-logging as provided when deployment mode WAR is selected
• Spring Boot shouldn't reconfigure the LogSystem when deployment mode is WAR

I hope you find this bug report helpful. Thanks in advance for looking into it!

Kind regards, Philipp

[wilkinsona]

By excluding spring-boot-starter-logging but leaving the logging system enabled, I suspect you've created a situation where both Boot and Wildfly think that they control the logging configuration. As you've described, the problem can be avoided by excluding spring-boot-starter-logging and setting org.springframework.boot.logging.LoggingSystem to none. This puts Wildfly fully in control.

Alternatively, I believe you could have used a jboss-deployment-structure.xml file to exclude JBoss's logging classes/subsystem which would prevent it from polluting the application with server classes. Generally speaking, we prefer this approach as it isolates the application from the server as much as possible which can improve reliability and portability.

• Spring initialz should add spring-boot-starter-logging as provided when deployment mode WAR is selected

We can't do that as it isn't a default that will work for everyone. Those using app servers other than Wildfly may not have this problem at all, and those using Wildfly with a jboss-deployment-structure.xml file won't have it either.

• Spring Boot shouldn't reconfigure the LogSystem when deployment mode is WAR

Similarly, I don't think we can do this as some war deployments will want the logging system while others may not depending on the development team's preferences and the app server.

Thanks for the report but I don't think there's anything we can do here. The problems that you are encountering are, in our experience, typical of deploying applications to an app server. Eliminating these problems is a large part of why the uber-jar deployment approach has proven so popular across the Java ecosystem. Unfortunately, I don't think there's anything that we can do that would avoid the problems for everyone as there are competing needs here.