Spring Boot supports configuring logging levels using environment variables, as described in https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.logging.log-levels. Generally such variables are expected to be suffixed with the category to adjust, giving LOGGING_LEVEL_ROOT for the root logger or LOGGING_LEVEL_X_Y_Z for the x.y.z category.

When the bare (without suffix) LOGGING_LEVEL environment variable is defined in the environment, startup fails with an opaque error:

***************************
APPLICATION FAILED TO START
***************************

Description:

Failed to bind properties under 'logging.level' to java.util.Map<java.lang.String, org.springframework.boot.logging.LogLevel>:

    Reason: org.springframework.core.convert.ConverterNotFoundException: No converter found capable of converting from type [java.lang.String] to type [java.util.Map<java.lang.String, org.springframework.boot.logging.LogLevel>]

Action:

Update your application's configuration

This can be difficult to debug, especially when one is not aware of the LOGGING_LEVEL environment variable functionality, did not introduce the LOGGING_LEVEL variable into the environment and is not aware of its presence, or both.

Improve the handling of this condition by interpreting LOGGING_LEVEL as LOGGING_LEVEL_ROOT, by ignoring LOGGING_LEVEL, by emitting a clearer error message, or in another suitable way.

Comment From: wilkinsona

Thanks for the report, @n12c. I agree that the output could be improved here.

At least part of the problem is that the BindException that is thrown has a null property. This means that there's no information in the error output about the value and origin of the logging.level property.

@mbhave @philwebb, the property is null because, when using AggregateElementBinder, context.setConfigurationProperty(property) is not called prior to attempting to convert the String into a Map. Adding that call is straightforward, but I'm wary of regressing something. Could you please take a look and see if I've overlooked something? FWIW, the changes build cleanly.

Comment From: mbhave

I wonder if we need to clear it once it's bound?

Comment From: wilkinsona

Thanks, @mbhave. That's one of the reasons that I was worried about regressing something. Looking at other places where a configuration property is set on the context, clearing it seems to be done asymmetrically so I couldn't figure out if/when it should be cleared in this case.

Comment From: philwebb

We think the clearConfigurationProperty isn't required. Looking at IndexedElementsBinder clear isn't called either.