You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a failure occurs while loading an ApplicationContext in the Spring TestContext Framework, it would be useful to have a first-class SPI for processing the exception.
For example, Spring Boot's testing support currently has a SpringBootDependencyInjectionTestExecutionListener that is responsible for generating a detailed failure report to help diagnose what went wrong; however, Spring Boot has to replace the standard DependencyInjectionTestExecutionListener with the Spring Boot specific one. In addition, the SpringBootDependencyInjectionTestExecutionListener has some drawbacks (see spring-projects/spring-boot#24888).
We should therefor introduce a first-class SPI in the TestContext framework for "processing" ApplicationContext load failures -- basically a new interface that third parties like Spring Boot can implement and register (potentially via the spring.factories mechanism).
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.
Closesspring-projectsgh-28826
sbrannen
added a commit
to sbrannen/spring-framework
that referenced
this issue
Oct 18, 2022
At the request of the Spring Boot team, ApplicationContextFailureProcessor
implementations are now loaded via the spring.factories mechanism
instead of supporting a single processor registered via subclasses of
AbstractTestContextBootstrapper.
This makes the retrieval and handling of processors internal to
DefaultCacheAwareContextLoaderDelegate, while simultaneously supporting
multiple processors that can be registered by anyone (i.e., not
limited to projects that implement custom TestContextBootstrappers).
See spring-projectsgh-28826Closesspring-projectsgh-29387
Overview
When a failure occurs while loading an
ApplicationContext
in the Spring TestContext Framework, it would be useful to have a first-class SPI for processing the exception.For example, Spring Boot's testing support currently has a
SpringBootDependencyInjectionTestExecutionListener
that is responsible for generating a detailed failure report to help diagnose what went wrong; however, Spring Boot has to replace the standardDependencyInjectionTestExecutionListener
with the Spring Boot specific one. In addition, theSpringBootDependencyInjectionTestExecutionListener
has some drawbacks (see spring-projects/spring-boot#24888).We should therefor introduce a first-class SPI in the TestContext framework for "processing"
ApplicationContext
load failures -- basically a new interface that third parties like Spring Boot can implement and register (potentially via thespring.factories
mechanism).Related Issues
ApplicationContext
in the TestContext framework [SPR-9548] #14182The text was updated successfully, but these errors were encountered: