Previously, regular bean definitions for configuration properties classes
that attempt to use constructor binding were detected in a bean factory
post-processor, ConfigurationPropertiesBeanDefinitionValidator. This
validation examined every standard bean definition and failed if it
encountered one for a class that should have used constructor binding.
There were two downsides to this approach:
1. Reflection used to identify if the bean should be using constructor
binding triggered class loading that could prevent subsequent
instrumentation by a load-time weaver.
2. The cost of the validation was incurred when there was no
misconfiguration to report.
This commit replaces ConfigurationPropertiesBeanDefinitionValidator
with a failure analyzer. This failure analyzer only runs once a failure
has occurred and the application context is not going to complete
refresh. This avoids causing problems with subsequent instrumentation
and also avoids the cost of validation and error reporting unless there
is an error.
Fixes gh-20798
* gh-22207:
Polish "Rename NoneOfNestedConditions to NoneNestedConditions in example docs"
Rename NoneOfNestedConditions to NoneNestedConditions in example docs
Closes gh-22207
* gh-22214:
Polish "Fix unwrapping of captured PrintStream in test support's OutputCapture"
Fix unwrapping of captured PrintStream in test support's OutputCapture
Closes gh-22214
Since Spring Framework 4.3.0.RC2, a default embedded value resolver
has been registered with the bean factory when one is not otherwise
configured. This meant that placeholders in `@Value` would be resolved
with or without PropertyPlaceholderAutoConfiguration defining a
PropertySourcesPlaceholderConfigurer bean. However, placeholders in
bean definitions would only be resolved if a
PropertySourcesPlaceholderConfigurer was defined.
This commit updates PropertyPlaceholderAutoConfigurationTests to align
with this change in Framework. We now test that placeholders are
resolved in `@Value` annotations with or without the auto-configuration
and that placeholders in bean definitions are only resolved with the
auto-configured.
Closes gh-22230
Previously, if TomcatMetricsBinder destroy() was called before it had
received an ApplicationStartedEvent an NPE would be thrown due to
TomcatMetrics being null. This NPE was then caught and logged at
warning level by the disposable bean adapter.
This prevents the NPE by checking that the TomcatMetrics instance is
null before calling close() on it.
See gh-22141
Andy Wilkinson
Stephane Nicoll
Scott Frederick
Clayton Walker
XenoAmess
dreis2211
im47cn
Madhura Bhave
May