SpringBoot Order of applying and resolving within LoggingSystemProperties

This issue is reproducible in latest release 3.2.0 when using Logback with custom logback-spring.xml like:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <conversionRule conversionWord="somethingCustom" converterClass="..."/>
</configuration>

When defining the following two properties in a local config resource, the property placeholder of the level (LOG_LEVEL_PATTERN) within the console pattern is not resolved correctly or at least not in time

logging.pattern.level=%somethingCustom #conversion word can be converted to any string for simplified setup
logging.pattern.console=...${LOG_LEVEL_PATTERN:%5p}...%n...

The reason for that appears to be the order within LoggingSystemProperties#apply where CONSOLE_LOG_PATTERN is applied before LOG_LEVEL_PATTERN. Therefore within PropertyPlaceholderHelper#parseStringValue no according system property is found for LOG_LEVEL_PATTERN at the time of resolving CONSOLE_LOG_PATTERN and the default (here: %5p) is used. When patching this order within LoggingSystemProperties#apply the expected value (here: %somethingCustom) is printed.

This certainly is an edge case and can quickly be solved on user side, however I do think this behaviour is rather unexpected. Especially because the system property later is replaced with the correctly resolved string, implying a correct resolution which however is not true for the actual log.

Comment From: wilkinsona

Thanks for the report.

I'm rather torn on this one. While I can see why it would be beneficial to change the order in this particular case, I'm not sure it's something that we should support. Using LOG_LEVEL_PATTERN to refer to logging.pattern.level seems unnecessarily obscure to me and ${logging.pattern.level:%5p} would be more clear. I'll flag it for team discussion.

Comment From: philwebb

We discussed this today as a team and we're not keen to add to the property resolving complexity. Using system properties was the only option we had to get information to the logging system and we don't feel like these properties should be available when application.properties files are resolved.

We suggest using @wilkinsona's idea above to solve your problem.