Since @Bean methods are never used with externally specified constructor argument values but rather just with autowiring, the non-lenient constructor resolution mode is appropriate in case of an overloaded @Bean method, not performing any type difference weight checks. This change includes a refinement of Spring's existing non-lenient constructor resolution (which needs to be explicitly turned on and is therefore not well tested), narrowing the conditions for the ambiguity check (only in case of the same number of arguments and not for overridden methods).
Issue: SPR-10988
(cherry picked from commit b093b84)
Update `AbstractApplicationEventMulticaster` to support `EventObjects`
with a null source (which can happen if they have been serialized).
Issue: SPR-10945
(cherry picked from commit b0ff834e)
Ensure that property source locations are processed in the same order
regardless if the 'name' attribute is set or not.
Prior to this commit multiple locations from a `@PropertySource` with
a name were added to a `CompositePropertySource` in such a way that
the first location would take precedence. This has now been reversed
for consistence with unnamed `@PropertySource`s
Issue: SPR-10820
(cherry picked from commit e3d3d8cd)
Make ConfigurationClassPostProcessor Ordered.HIGHEST_PRECEDENCE in
case several BeanDefinitionRegistryPostProcessors are registered.
Issue: SPR-10645
(cherry picked from 350cb9b)
Previously ConfigurationClassParser could override a nested
@Configuration without consideration of @Bean's defined in parent
classes.
This commit ensures that if the original ConfigurationClass contains
additional bean definitions it is processed again.
Issue: SPR-10546
Use LinkedHashMaps/Sets wherever exposed to users, and code tests defensively in terms of expected Map/Set ordering. Otherwise, there'll be runtime order differences between JDK 7 and JDK 8 due to internal HashMap/Set implementation differences.
Issue: SPR-9639
(cherry picked from commit 9c09a0a)
In particular, avoid accidental usage of ASM for core JDK types - which will fail in case of a new bytecode version in the JDK, even if the application itself has been compiled with an earlier bytecode target.
Issue: SPR-10292
(cherry picked from commit d3a4068)
Just AsyncAnnotationBeanPostProcessor switches "beforeExistingAdvisors" to "true" by default. So effectively, MethodValidation/PersistenceExceptionTranslationPostProcessor apply after existing advisors by default again, fixing the 3.1->3.2 regression.
Issue: SPR-10309
The problem was that clocks go forward *at* 2am, so
2am doesn't exist once a year. Users might be surprised
that their cron trigger doesn't go off one night, but that
is arguably correct (and what happens now). The test can be
modified if we decide to change the trigger behaviour.
