This commit updates BeanFactoryAwareGeneratorStrategy to extend
ClassLoaderAwareGeneratorStrategy in order to avoid duplication of the
common generate() implementation.
Closes gh-24396
Prior to this commit, Spring offered two top-level implementations of
the BeanNameGenerator strategy: DefaultBeanNameGenerator and
AnnotationBeanNameGenerator. The latter is used as the default bean
name generator for beans picked up via component scanning. In a typical
application, this strategy works well; however, if multiple component
scanned beans have the same simple class name (i.e., identical names
ignoring the package), a BeanDefinitionStoreException is thrown.
To address such naming conflicts, users of Spring have had to implement
a custom BeanNameGenerator based on the fully qualified class name of
such components.
Similar conflicts can arise with components registered via
configuration class imports (i.e., via @Import), and
ConfigurationClassPostProcessor addresses this via an anonymous inner
class that extends AnnotationBeanNameGenerator but falls back to using
the fully qualified class name if an explicit bean name is not provided
via an annotation.
This commit extracts the implementation of
ConfigurationClassPostProcessor's internal BeanNameGenerator into a new
top-level FullyQualifiedAnnotationBeanNameGenerator class that can be
used to disambiguate between same-named components residing in
different packages that are picked up via component scanning. This bean
name generator can be configured via @ComponentScan's nameGenerator
attribute.
Closes gh-24114
Prior to this commit, InstantFormatter was able to properly serialize
an Instant that is far in the future (or in the past), but it could not
properly deserialize it, because in such scenarios an ISO-formatted
Instant starts with a +/- sign.
This commit fixes this issue, while maintaining the previous contract,
and also introduces tests for InstantFormatter.
Closes gh-23895
Currently, if you have an optional event listener (via a @Bean method returning `null`)
this causes the event multicaster to explode violently. Now, we just safely skip it.
Prior to this commit, the `DateFormatterRegistrar` would register the
annotation-based formatter before the pattern-based formatter. This
would create an issue when an application tries to convert a `String` to
an annotated `@DateTimeFormat Date`: since the converters are considered
in reversed order of registration in
`GenericConversionServicei#ConvertersForPair`, the pattern-based variant
would always be considered before the annotation-based variant,
overriding the developer's opinion.
This commit aligns the `DateFormatterRegistrar` with the
`DateTimeFormatterRegistrar` and registers the annotation-based variant
last.
Closes gh-23893
