Allow a TestExecutionListener to configure the ApplicationContext [SPR-5185]

[spring-projects-issues]

Tuomas Kiviaho opened SPR-5185 and commented

Status Quo

Currently the application context gets refreshed by the loader itself. So the only option to configure the XmlBeanDefinitionReader, PassthoughSourceExtrator, etc. without a double refresh is to extend or implement a ContextLoader.

Proposal

A ContextLoader could return a non-refreshed ApplicationContext to the TestContextManager and leave refreshing to a new configurable application context aware TestExecutionListener that would ensure that the ApplicationContext has been properly initialized before test methods and refresh it as needed or every time (based on the presence of the @DirtiesContext annotation).

---

Affects: 2.5.5

Attachments:

• TestContext.patch (3.01 kB)
• TestContextManager.patch (2.62 kB)

3 votes, 4 watchers

[spring-projects-issues]

Tuomas Kiviaho commented

I commented #9309 a while back about utilizing test execution listeners to register default annotation post processors (and shutdown hook). This one goes to the same area.

[spring-projects-issues]

Tuomas Kiviaho commented

Extending of the context loader and test execution listeners could be made transparent to the tests themselves (Spring JavaConfig for instance requires explicit 'loader' definition for each type.

Patches contain direct ServiceLoader implementation which allows treating any interface/abstract class as service but expanding target @ContextConfiguration to package level would be an alternative (and in my opinion more elegant) approach. I have no idea how @Inherited is supposed work on package level but I guess it doesn't mean parent folder.

[spring-projects-issues]

Sam Brannen commented

Tuomas Kiviaho, with the new support for ApplicationContextInitializers introduced in Spring Framework 3.2, do you still see a need for programmatic configuration of the ApplicationContext beyond what one can achieve with an ApplicationContextInitializer?

[spring-projects-issues]

Sam Brannen commented

Since there have not been any comments of votes for this issue in several years, I am resolving this issue as Won't Fix, based on the assumption that support for ApplicationContextInitializers is sufficient.