Previously, @ConfigurationProperties was not annotated with @Indexed.
This meant that @ConfigurationPropertiesScan would not be able to
find them when the underlying
ClassPathScanningCandidateComponentProvider is using a
CandidateComponentsIndex.
This commit annotated @ConfigurationProperties with @Indexed so that
they can be found by index-based scanning.
Fixes gh-26459
Update `BufferingApplicationStartup` to use thread safe data structures.
Prior to this commit, it was possible for calls from different threads
(for example due to request scope beans) to cause a
NoSuchElementException to be thrown.
Closes gh-25792
Previously, classes involved in config loading used a variety of
potentially different class loaders when calling SpringFactoriesLoader.
Some classes would use their own class loader and others would use null
which results in SpringFactoriesLoader's class loader being used.
This commit updates the config loading classes to consistently use the
resource loader's class loader.
Fixes gh-26126
This commit modifies the integration tests for the Maven and Gradle
image building goal and task to use a custom builder as a test harness
to verify that the plugins invoke the builder as expected.
Fixes gh-25838
This commit fixes a flawed assertion that was relying on a log message
to validate the TaskExecutor is lazy. The level of the log message has
changed in framework and broke the test. We now rather check the bean
definition.
Additional profiles were being processed after config file processing
when legacy processing was used.
This commit also restores the order in which additional profiles are added
when legacy processing is used.
Active profiles take precedence over additional profiles.
See gh-25817
Additional profiles were being processed after config file processing
when legacy processing was used.
This commit also restores the order in which additional profiles are added
when legacy processing is used.
Active profiles take precedence over additional profiles.
See gh-25817
This commit fixes a flawed assertion that was relying on a log message
to validate the TaskExecutor is lazy. The level of the log message has
changed in framework and broke the test. We now rather check the bean
definition.