Logback 1.5.5 and 1.5.6 incompatible with springProfile

[AFulgens]

With Logback 1.5.5 fixes have been introduced for the inclusion resolution. (From the release notes: "Fixed issue where file inclusion would ignore any previously defined variables.")

This caused some side-effects that have been presumed to be fixed with #805. However, springProfile conditionals are still broken.

Reproduction

I have tested the following with org.springframework.boot:spring-boot-starter-parent:3.2.4 (and some earlier minor version) with ch.qos.logback:logback-classic:1.5.4, ...:1.5.5, and ...:1.5.6 together with org.slf4j:slf4j-api:2.0.13. Logback 1.5.4 works, 1.5.5 breaks, and 1.5.6 stays broken.

<property name="LOG_FORMAT" value="JSON"/>

<springProfile name="(local | test)">
    <property name="LOG_FORMAT" value="PLAIN"/>
</springProfile>

Playing around with it, e.g.,

<springProfile name="(local | test)">
    <property name="LOG_FORMAT" value="PLAIN"/>
</springProfile>
<springProfile name="!(local | test)">
    <property name="LOG_FORMAT" value="JSON"/>
</springProfile>

does NOT fix the issue, in the latter case the variable is simply not set.

From this I conclude the springProfile is with Logback 1.5.5 and above plain broken. See https://docs.spring.io/spring-boot/reference/features/logging.html#features.logging.logback-extensions for the descriptions of this extension. I would be inclined to open a ticket at SpringBoot (https://github.com/spring-projects/spring-boot) for this, but I could not pinpoint it to a specific patch release of Logback, so here it is.

Expected behaviour

The propery is set behind a springProfile guard. (My assumption is that the springProfile simply cannot be evaluated, so any other XML inside would not be parsed either.)

[ceki]

I believe this issue is related to spring-boot/issues/40491 which was fixed in spring-boot 3.3.0 (which seems like not yet released as of 2024-05-21)

[AFulgens]

@ceki Thanks for the find, I was apparently blind that I did not find this in the spring-boot issues (I admit, I might not have searched in already closed issues). They marked it as closed, because internally they are using Logback version 1.4.14 for pre 3.3.0, thus only those consumers see the issue, who are upgrading Logback on their side. Pity.

This would mean that this can be closed here?

Spring Boot will have to adapt their extension, which will be done at a later date. Thanks for looking into it nevertheless!

[ceki]

@AFulgens If you could please test and report back here, that would be great.

[AFulgens]

That'll have to wait until Friday/next week, because I don't have a setup where I can integrate an RC version of Spring Boot (planned release date for 3.3.0 is 2024-05-23, i.e., Friday). Will keep you posted as soon as I can.

[AFulgens]

Validated:	Logback Version	Sprint Boot Version	Result
1.5.4	3.2.4	✔️
1.5.4	3.3.0	❌¹
1.5.6	3.2.4	❌²
1.5.6	3.3.0	✔️

¹ with Caused by: java.lang.IllegalStateException: java.lang.NoSuchMethodError: 'void ch.qos.logback.core.model.processor.ModelInterpretationContext.setConfiguratorSupplier(java.util.function.Supplier)' ² springProfile in the XML config is b0rked, i.e., not parsed.

Additionally, upgrading broke some of my tests in the project, where I was validating Spring Boot startup logging. Namely, that it does not emit any WARNs/ERRORs. As of the new Logback version I have messages like

15:31:36,227 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.springframework.boot.actuate.endpoint.jmx] to WARN
15:31:36,227 |-INFO in ch.qos.logback.classic.jul.LevelChangePropagator@6be618a7 - Propagating WARN level on Logger[org.springframework.boot.actuate.endpoint.jmx] onto the JUL framework

... and thus my regex (.*(WARN|ERROR).*) triggers 🤪 But I can live with that, I'll just have to adjust the tests.

---

My bottomline: this ticket can be closed, it's a "consumer problem" from the Spring Boot point of view (i.e., Spring Boot is the consumer of Logback). The only unfortunate thing it that it is a patch version of Logback, which introduced an incompatibility.

[ceki]

@AFulgens Thank you for the update.