This commit introduces TestAotProcessor which replaces
ProcessTestsAheadOfTimeCommand, removes the dependency on picocli, and
aligns with the implementation of the AotProcessor in Spring Boot.
TestAotProcessor is a command-line application (CLI) that scans the
provided classpath roots for Spring integration test classes and then
generates AOT artifacts for those test classes in the provided output
directories.
This CLI is only intended to be used by build tools.
Closes gh-28825
This commit introduces ProcessTestsAheadOfTimeCommand, a command-line
application (CLI) that scans the provided classpath roots for Spring
integration test classes and then generates AOT artifacts for those
test classes in the provided output directories.
This CLI is only intended to be used by build tools.
Closes gh-28825
This commit introduces initial AOT run-time support in the Spring
TestContext Framework.
- DefaultCacheAwareContextLoaderDelegate: when running in AOT mode, now
loads a test's ApplicationContext via the AotContextLoader SPI
instead of via the standard SmartContextLoader and ContextLoader SPIs.
- DependencyInjectionTestExecutionListener: when running in AOT mode,
now injects dependencies into a test instance using a local instance
of AutowiredAnnotationBeanPostProcessor instead of relying on
AutowireCapableBeanFactory support.
Closes gh-28205
TestContextAotGenerator now uses AotTestMappingsCodeGenerator to
generate a AotTestMappings__Generated.java class which is loaded in
AotTestMappings via reflection in order to retrieve access to
ApplicationContextIntializers generated during AOT processing.
Furthermore, the processAheadOfTimeAndGenerateAotTestMappings() method
in TestContextAotGeneratorTests now performs a rather extensive test
including:
- emulating TestClassScanner to find test classes
- processing all test classes and generating ApplicationContextIntializers
- generating mappings for AotTestMappings
- compiling all generated code
- loading AotTestMappings
- using AotTestMappings to instantiate the generated ApplicationContextIntializer
- using the AotContextLoader API to load the AOT-optimized ApplicationContext
- asserting the behavior of the loaded ApplicationContext
See gh-28205
Closes gh-28204
This commit introduces a dedicated AotContextLoader extension of
SmartContextLoader and reverts the recent changes to the existing
contract for SmartContextLoader. This allows existing
SmartContextLoader implementations to continue working unaffected by
AOT support unless they opt into AOT support by explicitly implementing
the new AotContextLoader contract.
In addition, existing SmartContextLoader implementations in the
spring-test module have been modified to implement AotContextLoader
instead of SmartContextLoader. This allows the core framework to
provide built-in AOT support in the TestContext framework, and it also
allows third-party extensions to built-in SmartContextLoaders to
participate in AOT processing and run-time support transparently (or at
least as transparent as possible).
Closes gh-28906
This commit introduces TestContextAotGenerator for processing Spring
integration test classes and generating AOT artifacts. Specifically,
this class performs the following.
- bootstraps the TCF for a given test class
- builds the MergedContextConfiguration for each test class and tracks
all test classes that share the same MergedContextConfiguration
- loads each test ApplicationContext without refreshing it
- passes the test ApplicationContext to ApplicationContextAotGenerator
to generate the AOT optimized ApplicationContextInitializer
- The GenerationContext passed to ApplicationContextAotGenerator uses
a feature name of the form "TestContext###_", where "###" is a
3-digit sequence ID left padded with zeros.
This commit also includes tests using the TestCompiler to verify that
each generated ApplicationContextInitializer can be used to populate a
GenericApplicationContext as expected.
See gh-28204
This commit revises 903e9f2a02 based on feedback from the Spring Boot
team.
- The original loadContext(MergedContextConfiguration) method is no
longer deprecated.
- loadContext(MergedContextConfiguration, boolean) has been replaced by
loadContextForAotProcessing(MergedContextConfiguration) which is
implemented as a `default` method that throws an
UnsupportedOperationException.
- Affected code has been refactored to adjust to these changes.
See gh-28906
Prior to this commit, the contract of the loadContext() method in the
SmartContextLoader SPI required that the ApplicationContext be returned
in a fully refreshed state with a JVM shutdown hook registered for it.
However, in order to support AOT processing within the Spring
TestContext Framework (TCF), we need a way to signal to
SmartContextLoader implementations that they should load the test's
ApplicationContext without refreshing it or registering a JVM shutdown
hook.
To address this issue, this commit:
- Introduces a new loadContext(MergedContextConfiguration, boolean)
method. The boolean `refresh` flag controls whether the returned
ApplicationContext should be refreshed and have a JVM shutdown hook
registered for it.
- Deprecates the existing loadContext(MergedContextConfiguration)
method in favor of loadContext(MergedContextConfiguration, boolean).
- Removes all use of the deprecated method within the spring-test
module, excluding the exception mentioned below.
Note that loadContext(MergedContextConfiguration, boolean) is
implemented as an interface `default` method which delegates to the
deprecated loadContext(MergedContextConfiguration) method for backward
compatibility. When migrating a SmartContextLoader to Spring Framework
6.0, implementations that directly implement the SmartContextLoader SPI
(instead of extending AbstractGenericContextLoader or
AbstractGenericWebContextLoader) will need to override the new
loadContext(MergedContextConfiguration, boolean) method in order to
honor the `refresh` flag for AOT processing support. See the
implementation in AbstractGenericContextLoader for an example of how
this can be achieved.
Closes gh-28906
For Spring Framework 6.0 we have decided to deprecate the obsolete
methods in the ContextLoader API in the Spring TestContext Framework in
favor of the methods in the SmartContextLoader API which has been
available since Spring Framework 3.1.
Closes gh-28905
- remove not-empty precondition check for packageNames so that the core
scan() method can actually be used.
- document constructor
- document use case for packageNames
- add test that scan's all test classes in the spring-test project
- reduce logging due to the previous action item
See gh-28824
This commit introduces the TestClassScanner which scans provided
classpath roots for Spring integration test classes using the JUnit
Platform Launcher API which allows all registered TestEngines to
discover tests according to their own rules.
The scanner currently detects the following categories of Spring
integration test classes.
- JUnit Jupiter: classes that register the SpringExtension via
@ExtendWith.
- JUnit 4: classes that register the SpringJUnit4ClassRunner or
SpringRunner via @RunWith.
- Generic: classes that are annotated with @ContextConfiguration or
@BootstrapWith.
The scanner has been tested with the following TestEngine
implementations for the JUnit Platform.
- JUnit Jupiter
- JUnit Vintage
- JUnit Platform Suite Engine
- TestNG Engine for the JUnit Platform
Closes gh-28824
Prior to this commit, if a cookie was added to MockHttpServletResponse,
the comment attribute was not included in the generated Set-Cookie
header. In addition, MockCookie.parse(String) did not support the
Comment attribute.
This commit addresses both of these issues.
Closes gh-28730
Given the availability of two alternatives mechanisms for URL path
matching, PathPatternParser and AntPathMatcher, and now that
parsed patterns are enabled by default, it makes sense to reduce the
proliferation of options on AbstractHandlerMapping by deprecating
shortcuts related to String path matching. Most applications rely
on Boot and on the MVC config to do all this.
See gh-28607
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
This commit contains changes made because of the introduction of
HttpStatusCode. In general, methods that used to return a HttpStatus
now return HttpStatusCode instead, and methods that returned raw status
codes are now deprecated.
See gh-28214
