Cannot disable "condition evaluation report"

[bsakweson]

I observed something today on a new app I stood up for PoC. For some strange reason I cannot turn off condition evaluation report. I have never ran into this before and I have been messing with Spring since mid 2000s. Did something change, I zapped through the document to see if something jumps out on me, but no luck so far. It is an inconvenience since it forces one to increase console buffer to see all the logs.

Spring-boot version: 3.4.2
I am basically using spring-boot-start-rest but turned on log4j2. Could that be the issue?

Here is the section of logging configuration:

  group:
    autoconfigure: "org.springframework.boot.autoconfigure"
    hikari: "com.zaxxer.hikari"
    web: "org.springframework.web"
  level:
    root: ERROR
    autoconfigure: WARN
    hikari: INFO
    web: INFO

Oh by the way, I do not remember setting debug=true anywhere in my application.yaml

Cheers!

[bsakweson]

Update:

I just noticed condition evaluation report shows up every time there is an error.

[wilkinsona]

I just noticed condition evaluation report shows up every time there is an error.

If the error's occurring when creating the application context in a test, that was always meant to happen but it has been broken for some time. It was fixed in #42185.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

[lnrs-tinsleyn]

Hi there, just wanted to second this issue.

The condition evaluation report appears whenever the application context fails to initialise in a test. Unfortunately it is very long and obscures the real reason for the failure (typically an init method failing or other user-land bean error and not to do with autoconfiguration). Because it is put directly into the System.err stream it is interleaved with other log lines that may also been written out, effectively fragmenting them.

I would really like to disable this. It would be good to have this at least go through a regular logger so it is possible to turn it off, or make it otherwise configurable?

[philwebb]

@lnrs-tinsleyn Thanks for comment. I'm not sure what we should do here, we probably can't use the regular logger because the context failed to start and so the logging system may not have been correctly initialized. Likewise, we can't easily offer a property to disable the report, because loading of application.properties may not have happened.

We might be able to look at a system property and disable the report if it is set. That won't really help if you want to disable the report for all tests.

Flagging for team attention to see if anyone else has any bright ideas.

[nosan]

Likewise, we can't easily offer a property to disable the report, because loading of
application.properties may not have happened.

I think a property to disable the report can be used because OnFailureConditionReportContextCustomizerFactory$ApplicationFailureListener is not registered if the Environment preparation fails when running tests with @SpringBootTest, and the ApplicationFailedEvent is not published when using @SpringJUnitConfig.

---

I've created a prototype of these changes in this branch.

I'm not sure about the name of the property to use. Currently, I'm considering spring.test.condition-evaluation-report.print, with possible values:

• system_err
• system_out
• none

[philwebb]

We have the existing spring.devtools.restart.log-condition-evaluation-delta property and spring.test.mockmvc.print is pretty similar. We do generally try to avoid names-with-dash in the middle of properties and I wonder if System.out vs System.err is needed. I might be tempted with a boolean spring.test.print-condition-evaluation-report=false or perhaps spring.test.print-condition-evaluation-report=always/never/on-failure. Let's see what the rest of the team think.

[philwebb]

Superseded by PR #45268. Thanks @nosan!