Migrate all AOT tests to make use of `GeneratedClasses` rather than
directly generating Java files. This commit also refines and polishes
AOT APIs to being greater consistency.
Specifically:
- The `MethodGenerator` interface has been removed in favor of
working directly with `GeneratedMethods`.
- The visibility of several constructors and methods has been
reduced to package-private.
- The `using(...)` and `builder` methods have been removed in
favor of setting the `Consumer` callbacks directly as
constructor arguments.
- Variable names for builders are now named `type` or `method`
depending on what they're building.
Closes gh-28831
Prior to this commit, when users wished to register proxy hints for a
Spring AOP JDK dynamic proxy, they were required to explicitly specify
SpringProxy, Advised, and DecoratingProxy along with user interfaces.
This commit simplifies hint registration for Spring AOP proxies by
introducing two completeJdkProxyInterfaces() methods in AopProxyUtils,
one that accepts strings and one that accepts classes that represent
the user-specified interfaces implemented the user component to be
proxied. The SpringProxy, Advised, and DecoratingProxy interfaces are
appended to the user-specified interfaces and returned as the complete
set of interfaces that the proxy will implement.
Closes gh-28745
Since users might not have a concrete need to work with TypeReference,
this commit introduces ProxyHints.registerJdkProxy(String...) to
simplify use of the API for registering a dynamic proxy based on fully
qualified class names of the required interfaces.
Closes gh-28781
The warning message logged for an annotation that still uses
convention-based overrides now includes a concrete suggestion for how
the problem may potentially be fixed.
WARN - Support for convention-based annotation attribute overrides is
deprecated and will be removed in Spring Framework 6.1. Please
annotate the 'locations' attribute in
@org.springframework.core.annotation.MergedAnnotationsTests$ConventionBasedComposedContextConfiguration
with an appropriate @AliasFor declaration -- for example,
@AliasFor(annotation = org.springframework.core.annotation.MergedAnnotationsTests$ContextConfiguration.class).
See gh-28760
This commit replaces convention-based annotation attribute overrides in
tests with explicit use of @AliasFor -- except for tests in spring-core,
since we still want to test our support for convention-based annotation
attribute overrides.
See gh-28760
Implicit convention-based annotation attribute overrides have been
supported for a long time; however, Spring Framework 4.2 introduced
support for explicit annotation attribute overrides via @AliasFor.
Since explicit overrides are favorable to implicit overrides, and since
the support for convention-based overrides increases the complexity of
Spring's annotation search algorithms, this commit deprecates
convention-based overrides and logs a WARNING whey the are encountered.
For example, the following message is logged for a test that still
uses convention-based overrides. A log message is generated for each
such attribute in a given annotation but only once per application run.
WARN Support for convention-based annotation attribute overrides is
deprecated and will be removed in Spring Framework 6.1. Please
annotate the 'basePackages' attribute in
@org.springframework.context.annotation.ConfigurationClassPostProcessorTests$ComposedConfigurationWithAttributeOverrides
with an appropriate @AliasFor declaration.
Closes gh-28760
AnnotationTypeMapping.addConventionMappings() sometimes adds
convention-based mappings that it should not.
For example, in certain circumstances an explicit annotation attribute
override configured via @AliasFor can be incorrectly mapped as
convention-based.
Although this does not appear to cause negative side effects (other
than unnecessary processing), this is technically a bug, and this
commit address this issue.
Closes gh-28773
Stephane Nicoll
Phillip Webb
rstoyanchev
Sam Brannen
Marc Wrobel
Juergen Hoeller
Sébastien Deleuze