This is a follow up for @GeorgeBarbosa comment on this https://github.com/spring-projects/spring-boot/issues/10470

Problem

When you have invalid entries on the application.yml file, for example duplicated ones, like this:

server:
  port: 8088

a: true

a: true

The application fail with the correct error message pointing to the problem.

08:15:21.716 [main] ERROR org.springframework.boot.SpringApplication - Application run failed
org.yaml.snakeyaml.constructor.DuplicateKeyException: while constructing a mapping
 in 'reader', line 1, column 1:
    server:
    ^
found duplicate key a
 in 'reader', line 6, column 1:
    a: true
    ^

However, this is printed to stdout since it happens before the Logging system initialization. When there is a logging configuration, this error will not be printed to the log files. The problem gets worse when the application is configured to start/stop in a linux service for example, since it just fail silently and you have to introspect journalctl logs to figure out the problem.

I believe this happens because the application.yml parsing is happening before org.springframework.boot.context.logging.LoggingApplicationListener is invoked, which kind of makes sense since this listener depends on an ApplicationEnvironmentPreparedEvent which can only be fired when the yml file is successfully parsed and the properties loaded.

I've made a simple maven project to reproduce to this problem, it is attached here.

Thanks

Comment From: philwebb

We have a bit of a catch-22 here. We offer a number of logging properties so we must parse the YAML to configure the logging system, but if the YAML is invalid we want to log a problem!

About the only thing I can think of doing is trying to initialize the logging system when there's a failure with an empty Environment. That would work in your case because your logback-spring.xml file has <file>debug.log</file> hardcoded. For developers that use the logging.file.name property and use <file>${LOG_FILE}</file> it wouldn't work because we'd need to parse the YAML.

Comment From: philwebb

Flagging to see if anyone else on the team has ideas.

Comment From: joao-borges

@philwebb thanks for the quick response

just FYI what I am implementing on my app is the workaround you said, I am initializing logback manually because our stuff is mostly hardcoded but yea I can imaigne this being a problem for more dynamic configs.

Comment From: bclozel

We've just discussed this issue as a team and we haven't found a way to solve this particular problem in a generic way. We're closing this as a result. Thanks!