Prior to this commit, meta-annotations were unnecessarily synthesized
when attempting to synthesize a MergedAnnotation retrieved via the
MergedAnnotations.from(AnnotatedElement, ...).get(<annotationType>) API.
This is a regression in our merged annotation support that was
introduced when the MergedAnnotations API replaced our previous support.
This commit fixes this by revising the logic in TypeMappedAnnotation's
createSynthesizedAnnotation() method so that a meta-annotation is
returned unmodified if it is not synthesizable.
This commit also updates BootstrapUtilsTests, since @BootstrapWith
should never have been synthesized, and Class#getCanonicalName() is
only used in the toString() implementation of an annotation synthesized
by Spring or normal annotations on Java 19+ (see
https://bugs.openjdk.org/browse/JDK-8281462).
Closes gh-28704
Align IllegalStateException with SQLException handling and propagate
the original exception.
See gh-28669
Co-authored-by: Christoph Mies <chr.mi@web.de>
Since LoggingCacheErrorHandler was only recently introduced in 5.3.16,
we have decided to completely revise its internals (protected API) in
5.3.x while retaining the current public API.
Specifically, this commit:
- introduces protected getLogger() and isLogStackTraces() methods to
improve extensibility
- revises logCacheError() to accept a Supplier<String> for lazy
resolution of error messages
Closes gh-28672
See gh-28670, gh-28648
At present, creating a LoggingCacheErrorHandler that logs stack traces
also requires supplying the logger to be used. This might be
inconvenient for some users, as it requires usage of the Commons
Logging API.
This commit simplifies creation of such as LoggingCacheErrorHandler
instance by adding a constructor that only accepts a boolean flag
indicating whether to log stack traces.
Closes gh-28670
Update test detecting RouterFunction beans in parent contexts to use
different bean names and avoid shadowing. Changed the fix accordingly
given that BeanProvider does detect beans in parent contexts.
See gh-28595
Prior to this commit, ObjectToObjectConverter considered the return
type of non-static `to[targetType.simpleName]()` methods but did not
consider the return type of static `valueOf(sourceType)`,
`of(sourceType)`, and `from(sourceType)` methods.
This led to scenarios in which `canConvert()` returned `true`, but a
subsequent `convert()` invocation resulted in a
ConverterNotFoundException, which violates the contract of the
converter.
This commit addresses this issue by taking into account the return type
of a static valueOf/of/from factory method when determining if the
ObjectToObjectConverter supports a particular conversion. Whereas the
existing check in `determineToMethod()` ensures that the method return
type is assignable to the `targetType`, the new check in
`determineFactoryMethod()` leniently ensures that the method return
type and `targetType` are "related" (i.e., reside in the same type
hierarchy).
Closes gh-28609
Sam Brannen
Stephane Nicoll
Kevin Schönfeld
Vedran Pavic
Jerome Prinet
Sébastien Deleuze
Lars Grefer
Johnny Lim
Spring Builds
Fabian Gonzalez
Juergen Hoeller
rstoyanchev
Arjen Poutsma