Previously, Slf4jLoggingSystem would install SLF4JBridgeHandler into
JUL but would only remove a single root handler that was a
ConsoleHandler. If there were was than one root handler or the single
root handler was of a different type, they would not be uninstalled.
When deploying an application to Tomcat, this led to duplicate log
messages appearing in Tomcat’s console output and to logging from
other application or Tomcat itself being routed into an
application-specific log file enabled using the logging.file
configuration property.
A secondary, related problem was that LogbackLoggingSystem installs a
LevelChangePropagator so that Logback’s log level configuration is
propagated into JUL. This meant that an individual Boot app with
custom log level configuration could change the log levels of Tomcat
itself and of any other applications that had been deployed to Tomcat
and use JUL.
This commit updates both Slf4jLoggingSystem and LogbackLoggingSystem
so that they only change JUL’s configuration if it hasn’t already been
customized. The configuration is deemed to have not been customised if
there’s a single root handler and its a console handler.
Closes gh-13470
Before 2.0.2, if profiles were activated via the environment using the
active and include profile property, profiles specified via the active
property would take precedence. This commit restores that behavior.
Fixes gh-13513
Refine the property source cache key fix so that a copy of the
key is only taken when the values change. This allows us to
retain the previous performance optimization of not creating
unnecessary string arrays.
Closes gh-13344
Update `SpringIterableConfigurationPropertySource` so that the cache
key from a `MapPropertySource` is invalidated when the map contents
changes.
Prior to this commit, the actual keys of the map were used as the key.
This meant that if the underlying map changed, they key wouldn't be
invalidated because it ultimately pointed to the same object instance.
See gh-13344
Update `ConfigFileApplicationListener` to correctly load properties
that have `spring.profiles` values containing a list.
Prior to this commit the loaded would attempt to add the same document
twice resulting in a "property source cannot be added relative to
itself" error.
Closes gh-13362
Update `ConfigFileApplicationListener` to ensure that a
`spring.profiles.include` property that refers to an already processed
profile doesn't cause an infinite loop.
Closes gh-13361
Update `ConfigFileApplicationListener` so that `spring.profiles.include`
properties do not override higher priority active profiles.
This commit also changes when profiles get added to the environment.
Profiles are now added to the environment at the time of profile
processing so that they get logged in the order that they are processed.
Closes gh-13151
Update `InetAddressFormatterTests` to ensure that DNS resolvers that
return a "help" page for missing domains don't cause the build to fail.
Closes gh-11897
As of Spring Framework 5.1, we're depending on the Reactor Californium
release train.
Reactor Netty is now at version 0.8 and changed its artifact
coordinates, package names and broke several APIs. Spring Framework is
now up-to-date with those changes and this commit does the same for
Spring Boot.
Note that in that process, the `NettyServerCustomizer` has been changed
since the former `HttpServerOptions.Builder` API is now gone from
Reactor Netty, and we're now relying on immutable server instances
instead of a stateful builder pattern.
See gh-13321
