Review default exclusion mechanism in AOT-optimized contexts #29280
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
theme: aot
An issue related to Ahead-of-time processing
type: task
A general task
Milestone
Right now, we do the following:
BeanFactoryInitializationAotProcessor
on a bean, it is excluded (with no way to have it back)BeanRegistrationAotProcessor
on a bean, it is excluded by default and that can changed by overriding theisBeanExcludedFromAotProcessing
methodBeanRegistrationExcludeFilter
. Such interface must be implemented with eitherBeanFactoryInitializationAotProcessor
orBeanRegistrationAotProcessor
.The shortcut for "exclude myself" on
BeanRegistrationAotProcessor
is quite handy so I don't think relying only on the filter in its current form is ok. However, we should probably consider renaming the method as it doesn't exactly state what it does right now (the bean is processed and its contribution is recorded, but the bean itself won't be registered).spring-projects/spring-boot#32542 is another example. We have a
BeanDefinitionRegistryPostProcessor
that's exposed as a bean. The outcome of the post-processor (registering bean definitions) is recorded by AOT but the bean itself is contributed. This means that at runtime those bean definitions are contributed again.Excluding them by default might not be the best option as they could potentially implement extra interface and having them excluded with no signal can be quite misleading.
The text was updated successfully, but these errors were encountered: