Unwanted Logback status messages are sometimes logged during startup #34505
Comments
spring-projects-issues
added
the
status: waiting-for-triage
|
Thanks for the suggestion, but I'm not sure we can add the |
philwebb
added
the
status: waiting-for-feedback
|
Hi @philwebb Running the sample app generates those log messages on startup. |
spring-projects-issues
added
status: feedback-provided
|
Hi @philwebb Running the sample app generates those log messages on startup. |
|
And just to add to this, I also get a lot of INFO logs, and one WARN for "org.springframework.boot.context.properties.source.ConfigurationPropertySourcesPropertyResolver$DefaultResolver" I don't have an app that I have made for this test, I just think the issue is the same as for the "org.springframework.jndi.JndiTemplate" |
Closed
naivetoby
pushed a commit
to naivetoby/spring-boot
that referenced
this issue
Mar 11, 2023
…l logback configuration is complete.
|
Hi, we are facing the same issue. Im having it triggered by the same codepath as @eu-rlarsen.
@philwebb , in our case, it is being triggered by the following log line:
Which is triggered by this code PropertySourcesPropertyResolver.logKeyFound. Steps to reproduce: logback-spring.xml <configuration>
<springProperty scope="context" name="APP_NAME" source="spring.application.name" />
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%-5level ${APP_NAME} %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="STDOUT" />
</root>
</configuration>application.properties # define a SERVICE_NAME env var to reproduce. Without SERVICE_NAME env it runs fine
spring.application.name=${SERVICE_NAME:my-service}Define a env variable Some findings edit: adding the stack of the call that is triggering the print errors issue |
|
We're also using While I wasn't yet able to pinpoint the exact cause, the following configuration element will suppress all logback status messages until this issue is fixed. Maybe it helps someone else stumbling over this issue. <configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
...Obviously, this will also hide any actual configuration issues your configuration might contain, so use with care. You could also implement your own status listener that does not fully suppress the output. |
|
We are facing the same issue: as @chicobento already stated, the code that applies the system properties is executed twice. First time in and then again in Line 298 LogBackLoggingSystem.reinitialize: @Override
protected void reinitialize(LoggingInitializationContext initializationContext) {
getLoggerContext().reset(); // removes all appenders
getLoggerContext().getStatusManager().clear();
loadConfiguration(initializationContext, getSelfInitializationConfig(), null);
}
@Override
protected void loadConfiguration(LoggingInitializationContext initializationContext, String location,
LogFile logFile) {
if (initializationContext != null) {
applySystemProperties(initializationContext.getEnvironment(), logFile); // effectively calls apply the second time
}
...
}
protected void apply(LogFile logFile, PropertyResolver resolver) {
setSystemProperty(resolver, EXCEPTION_CONVERSION_WORD, "logging.exception-conversion-word");
setSystemProperty(PID_KEY, new ApplicationPid().toString());
setSystemProperty(resolver, CONSOLE_LOG_PATTERN, "logging.pattern.console"); // <--- this line calls logKeyFound, but no appenders are present in this run
...
}Possible fix if (initializationContext != null) {
applySystemProperties(initializationContext.getEnvironment(), logFile);
}must not be called after the The breaking change was possibly introduced with 3980c5a#diff-791625700b5f37dfa8f4e174ed25f81a353260de13287ac720d9cac682667361 |
wilkinsona
changed the title
wilkinsona
added
type: bug
wilkinsona
changed the title
|
There's a window where the deny-all turbo filter has been removed but Logback has not yet been configured. If any logging that would have reached an appender is performed in this window, the unwanted status messages will be logged. This window can be closed by ensuring that the turbo filter is in place. This is similar to the suggestion above but it needs to be done in such a way that we can be certain that the filter will be removed again. |
wilkinsona
added
type: regression
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I am a Java developer and I have found an issue with the SpringBoot 3.0.4 framework in the
org.springframework.boot.logging.logback.LogbackLoggingSystemclass, specifically on line 280.The current code is as follows:
I would like to suggest a modification to this method:
I hope this suggestion is helpful. Thank you for your work on this open source software.
Best regards,
Toby
The text was updated successfully, but these errors were encountered: