Filter ContextCustomizerFactory implementations that are only necessary at build time

[snicoll]

Overview

Consider the following use case:

@SpringBootTest
@Import(SomeConfiguration.class)
class MyTest { ... }

At build time, the processing of @SpringBootTest registers the necessary infrastructure to parse SomeConfiguration. At runtime, this process runs again (because it is part of SpringBootTestContextBootstrapper, via ImportsContextCustomizer).

Parsing configuration classes in a native image should not happen as it was done already at build time.

Deliverables

This task is to validate that the right AOT infrastructure is generated with such a test and to prevent it from happening again at runtime.

There might be other ContextCustomizer implementations that are running twice and should be handled the same way.

[sdeleuze]

This is breaking petclinic-jdbc tests (at least) so let's try to solve it for RC1.

[snicoll]

@sbrannen can you please give us a status update of what you've tried so that I don't duplicate the effort?

[snicoll]

Everything goes in the direction of being able to swap the TestContextBootstrapper that the test uses. We won't be able to get that short term so rewriting spring.factories to remove org.springframework.boot.test.context.ImportsContextCustomizerFactory could be one good option.

[sbrannen]

Everything goes in the direction of being able to swap the TestContextBootstrapper that the test uses.

Indeed, that may be the most robust solution in the end.

We won't be able to get that short term so rewriting spring.factories to remove org.springframework.boot.test.context.ImportsContextCustomizerFactory could be one good option.

I thought about that as well, but the thing is that the context customizers have to be present/instantiated/registered in order for the MergedContextConfiguration to do its job as the key for the ContextCache.

[sbrannen]

@sbrannen can you please give us a status update of what you've tried so that I don't duplicate the effort?

I didn't have a solution in place. Rather, I was investigating/contemplating possible solutions.

One thing I was considering was "caching" the calculated ContextCustomizerKey (or what it needs as input) for the ImportsContextCustomizer at build time, making that available via some generated factory (or similar approach), and then implementing a native substitution for the ImportsContextCustomizer constructor that (re)builds the ContextCustomizerKey from input retrieved from the generated factory -- effectively bypassing the ContextCustomizerKey#determineImports(Set<Annotation>, Class<?>) logic within the native image.

[snicoll]

Let's follow-up on #1262 for the cache key problem.