Closed AFulgens closed 2 months ago
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)
@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!
@AFulgens If you could please test and report back here, that would be great.
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.
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.
@AFulgens Thank you for the update.
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) withch.qos.logback:logback-classic:1.5.4
,...:1.5.5
, and...:1.5.6
together withorg.slf4j:slf4j-api:2.0.13
. Logback1.5.4
works,1.5.5
breaks, and1.5.6
stays broken.Playing around with it, e.g.,
does NOT fix the issue, in the latter case the variable is simply not set.
From this I conclude the
springProfile
is with Logback1.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 thespringProfile
simply cannot be evaluated, so any other XML inside would not be parsed either.)