`ContextCustomizer` does not respect lifecycle best practices

org.springframework.test.context.ContextCustomizer has been introduced to allow implementations to customize the context programmatically. Looking at implementations of the interface, it is primarily used in Spring Boot.

The unique method states the following:

Customize the supplied ConfigurableApplicationContext after bean definitions have been loaded into the context but before the context has been refreshed.

There are two main use cases I can see:

• Mutate the environment to enable/disable something
• Contribute more (test-related) beans

Because the context is not refreshed, the second bit should really register a bean definition and let the container creates it like any regular bean. ConfigurableApplicationContext does not expose a way to register a bean definition and it does this on purpose to separate the layer of responsability. As a result, we can see a number of implementations using a cast to get access to the registry.

The other problem is that by providing ConfigurableApplicationContext, the implementation has access to a lot more than it should, in particular on a context that has not been refreshed yet. This leads to issues like https://github.com/spring-projects/spring-kafka/issues/2870.

I don't know if the problem is big enough to consider a refactoring but I think the casting does not look right.

Start with org.springframework.test.context.ContextCustomizer and inspect the implementations mentioned in Spring Boot, focusing on casts used to access bean-definition registration and on the supplied ConfigurableApplicationContext. Review the related spring-kafka issue for the lifecycle concern; done would require an agreed refactoring that preserves environment customization and supports test bean registration without exposing inappropriate context operations.