Logback "loadConfiguration" too strict with errors (on resources/files)

[dharrigan]

Hi,

Currently in Spring Boot 1.4.0M3, in LogbackLoggingSystem within the method "loadConfiguration", the check for Status.ERRORS is too strict when it comes to missing property resources/files. Under normal logback conditions, Logback logs the error but continues onwards. In Spring Boot, the startup is aborted.

For example, in a logback-spring.xml configuration:

<property resource="blahblah.properties">
<property file="/a/directory/blahblah.properties"/>

Would cause the bootup to fail. Without using Spring Boot the error is echoed to the appender but ignored. It is quite often the case that this missing resources/files are fine, it doesn't affect the system and logback defaults to using the set values configured within the configuration file. So, being too strict here, IMHO, is too much.

In my view, if it is a Status.ERROR and if the Status.getOrigin == PropertyAction and if the message contains "Could not find" we should just skip onwards...

If I have some time, I'll put together a patch (and test if appropriate) for this.

-=david=-

[wilkinsona]

Failing fast is by design (see #3309). I'm not sure that we want to add much, if any logic, to decide what sort of errors should cause a failure. It feels like it could get overly complex. We'll discuss it, though.

[dharrigan]

Hi Andy,

Thank you very kindly for your quick response. I understand that fail fast is by design :-) It's good to know if my system won't boot up because I've forgotten something. However, with logging, the missing file or resource isn't a problem since it doesn't affect the system - insomuch that whatever properties or definitions have already been defined within the logback configuration will be used as-is. For example:

<root level="${root.log.level:-info}">
    <appender-ref ref="${platform.appender:-console}"/>
</root>

In production, I would set the root.log.level to "error" and platform.appender to "log". If I somehow forget to do this, it's no biggie, since the logging will still go to console and the level will be info. It won't stop my system from booting up.

Additionally, in development, Spring Boot fails to start up since these values are here - again, I am not concerned that in development the file or resources cannot be found, as logback would fallback to whatever is in the log file. However, the inclusion of these Logback elements and Spring Boot prevents me from running an almost-like production system, since I have to remove the elements manually, boot up spring, do whatever, then remember to uncomment the properties before commiting.!

I'm very hesitate to sprinkle my logback xml file with "springProperty" extensions as I want to keep my application as "agnostic" as possible, so relying on the existing mechanisms in logback to ignore missing properties/resources suits my use-case better.

Thank you kindly for the consideration.

-=david=-

[wilkinsona]

We've discussed this and decided that we want to keep the existing fail-fast behaviour

[dharrigan]

Thank you for the consideration. I'm sorry it didn't make it in, but perhaps I can contribute something else in future :-)