The counterpart of #28065 is that we need a way to start an ApplicationContext that has been pre-processed. Part of the refresh phase for such a context already ran, and therefore should not be invoked again.
Removing a low-level infrastructure, such as a BeanDefinitionRegistryProcessor implementation registered as a @Bean can be dangerous as said bean may implement extra interfaces (bean instance post-processing) that should actually run.
Starting a context this way should also provide the information that it runs in "AOT optimized mode" so that components can decide for themselves if they need to do something or rely on the AOT optimization.
Comment From: snicoll
A brainstorming with @wilkinsona helped make progress on this one. We could call the exact same callbacks (i.e. refresh rather an specific method) together with a "run level" that would indicate in which mode we're running:
- Regular (current runtime with no optimizations)
- Pre-processing optiomization (#28065)
- Runtime with pre-processing optimization (this issue)
Having such a high-level concept could be reused by Spring Boot when it needs to initializes components prior to the BeanFactory or the context itself.
Comment From: snicoll
Discussed this proposal with @jhoeller and one important point is that the component in charge of the refresh should be the one opting-in for a certain behavior (rather than a flag that could be set externally by anything). A new refresh(Mode mode) could achieve that where the existing refresh() method calls it with the "regular" mode.
We've also discussed the possibility to introduce a ModeAware interface that would let components declare they're interested in which mode the context is being refreshed.
Comment From: snicoll
We've decided to revisit this at an individual component level instead, leaving a global mode up to Spring Boot (see https://github.com/spring-projects/spring-boot/issues/30559)