This commit exposes a "spring.aot.processing" system property when the
AOT engine is running. This can be used by code that need to react
differently when the application is being refreshed for AOT processing.
Closes gh-29340
This commit introduces an ApplicationContextFailureProcessor SPI in the
Spring TestContext Framework that allows third parties to process
failures that occur while a SmartContextLoader attempts to load an
ApplicationContext.
SmartContextLoader implementations must introduce a try-catch block
around the loading code and throw a ContextLoadException that wraps
the failed ApplicationContext and the cause of the failure.
Extensions of AbstractTestContextBootstrapper can configure an
ApplicationContextFailureProcessor by overriding the new protected
getApplicationContextFailureProcessor() method.
DefaultCacheAwareContextLoaderDelegate unwraps any ContextLoadException
and delegates to the configured ApplicationContextFailureProcessor for
processing.
Closes gh-28826
There's currently a considerable amount of overlap between the
implementations of AotProcessor and TestAotProcessor. In addition
AotProcessor is abstract and does not include a main() method; whereas,
TestAotProcessor is concrete and does include a main() method.
To address these issues, this commit:
- Introduces an AbstractAotProcessor base class that AotProcessor and
TestAotProcessor now both extend
- Moves common properties/functionality to AbstractAotProcessor
- Renames AotProcessor to ContextAotProcessor
- Makes TestAotProcessor abstract like ContextAotProcessor
- Removes the main() method from TestAotProcessor
Closes gh-29266
Prior to this commit, the AOT runtime support in the Spring TestContext
Framework (TCF) relied on the MergedContextConfiguration for a given
test class being the same as during the AOT processing phase. However,
this is not always the case. For example, Spring Boot "disables"
selected `ContextCustomizer` implementations during AOT runtime
execution.
See 0f325f98b5
To address that, this commit ensures that context caching works
properly during AOT runtime execution even if the
MergedContextConfiguration differs from what was produced during the
AOT processing phase. Specifically, this commit introduces
AotMergedContextConfiguration which is a MergedContextConfiguration
implementation based on an AOT-generated ApplicationContextInitializer.
AotMergedContextConfiguration wraps the MergedContextConfiguration
built during AOT runtime execution.
Interactions with the ContextCache are performed using the
AotMergedContextConfiguration; whereas, the ApplicationContext is
loaded using the original MergedContextConfiguration.
This commit also introduces a ContextCustomizerFactory that emulates
the ImportsContextCustomizerFactory in Spring Boot's testing support.
BasicSpringJupiterImportedConfigTests uses @Import to verify that the
context customizer works, and AotIntegrationTests has been updated to
execute BasicSpringJupiterImportedConfigTests after test classes whose
MergedContextConfiguration is identical during AOT runtime execution.
Without the fix in this commit, BasicSpringJupiterImportedConfigTests
would fail in AOT runtime mode since its ApplicationContext would be
pulled from the cache using an inappropriate cache key.
Closes gh-29289
Prior to this commit, the abstract base test classes for JUnit 4 and
TestNG registered explicit sets of TestExecutionListeners. This
configuration was useful in the early years of the Spring TestContext
Framework. However, since the introduction of support for automatic
registration of "default" listeners in Spring Framework 4.1, these
predefined sets of TestExecutionListeners have become a hindrance to
using Spring's testing support with default listeners from Spring
portfolio projects (such as Spring Boot and Spring Security) as well as
third-party or project-specific default listeners.
To address this issue, the four abstract base test classes for JUnit 4
and TestNG no longer declare listeners via @TestExecutionListeners and
instead now rely on registration of default listeners.
Closes gh-29149
Prior to this commit, ExchangeResult.assertWithDiagnostics() threw an
IllegalArgumentException for a custom HTTP status code since toString()
invoked getStatus() without a try-catch block.
This commit addresses this issue by introducing a formatStatus() method
that defensively formats the response status, initially trying to
format the HttpStatus and falling back to formatting the raw integer
status code.
Closes gh-29283
TestClassScanner was made public with the assumption that Spring Boot's
AOT testing support might need to work directly with that class; however,
it turns out that Spring Boot does not currently have such a need.
In light of that, this commit restores TestClassScanner's visibility to
package private.
Prior to this commit, the TestRuntimeHintsRegistrar API combined
processing of MergedContextConfiguration and test classes. However, it
appears that only spring-test internals have a need for registering
hints based on the MergedContextConfiguration. For example, Spring
Boot's AOT testing support has not had such a need, and it is assumed
that third parties likely will not have such a need.
In light of that, this commit simplifies the TestRuntimeHintsRegistrar
API so that it focuses on processing of a single test class.
In addition, this commit moves the hint registration code specific to
MergedContextConfiguration to an internal mechanism.
Closes gh-29264
This commit updates code generation to customize the instantiation of
a configuration class that requires a proxy. Rather than instantiating
the raw class, the proxy is used.
Closes gh-29107
New methods in DefaultResponseCreator for adding headers and cookies,
for specifying the character encoding when setting a string body on
a response, which is useful when working in environments that do not
automatically assume UTF-8, such as integrating with legacy
applications from a new Spring one.
New methods in MockRestResponseCreators support extra commonly used
HTTP status codes, including some that occur when working in AWS,
CloudFlare, or when using gateways such as Kong, where resilient
applications should be able to respond to ratelimits, gateway errors,
and gateway timeouts that may occur if a remote service is down.
Added test cases for any changes made.
See gh-27280
This commit updates ClassNameGenerator so that it uses a ClassName for
its default target. This makes sure that a target that has been
generated can be used.
See gh-29027
This commit improves `TestCompiler` with a `with` function that allows
to customize a test compiler instance. Rather than `TestCompiler`
knowing about `TestGenerationContext`, the latter implements the
function so that it can be passed as is.
See gh-29175
The ability to set a system property to change the default
CacheAwareContextLoaderDelegate was only needed by the Spring Native
project in the Spring Framework 5.3.x line and should not be used by
other projects.
This commit therefore reverts the changes made in conjunction with
gh-27540.
Closes gh-29061
For certain use cases it is beneficial to be able to compute something
during AOT build-time processing and then retrieve the result of that
computation during AOT run-time execution, without having to deal with
code generation on your own.
To support such use cases, this commit introduces an AotTestAttributes
mechanism in the Spring TestContext Framework with the following
feature set.
- conceptually similar to org.springframework.core.AttributeAccessor in
the sense that attributes are generic metadata
- allows an AOT-aware test component to contribute a key-value pair
during the AOT build-time processing phase, where the key is a String
and the value is a String
- provides convenience methods for storing and retrieving attributes as
boolean values
- generates the necessary source code during the AOT build-time
processing phase in the TestContext framework to create a persistent
map of the attributes
- provides a mechanism for accessing the stored attributes during AOT
run-time execution
Closes gh-29100