A BeanDefinition can have an init and destroy method name. While uncommon, it is possible for a bean to have more than one of those, see InitDestroyAnnotationBeanPostProcessor.

To replace the runtime behavior of searching for those annotations, we need a way to specify multiple init and destroy method names. There might be an impact on isExternallyManagedConfigMember in RootBeanDefinition as well.

Comment From: snicoll

Reviewing what we did in Spring Native to support this feature, it looks like that adding multiple init/destroy method names could be enough to support this use case, if we'd honor MergedBeanDefinitionPostProcessor.

The current code registers detected method as externally managed. We could rather "just" register it and let the new code invokes the method.

Comment From: chenggwang

A BeanDefinition can have an init and destroy method name. While uncommon, it is possible for a bean to have more than one of those, see InitDestroyAnnotationBeanPostProcessor.

To replace the runtime behavior of searching for those annotations, we need a way to specify multiple init and destroy method names. There might be an impact on isExternallyManagedConfigMember in RootBeanDefinition as well.

Hi snico！So far, it seems that this support is only used in AOT. It doesn't seem to be used in other spring modules. For example, at least @bean(initMethod={"init1",init2,..." }), extending to xml configuration is obviously not supported. It seems that it is not needed elsewhere. So should this method be set as protected? Because we can directly accessible beanDefinition. SetDestroyMethodNames (init1 init2), if you really need to generality, the initialization method execution order how to guarantee? And how to coordinate?

Comment From: snicoll

Do you have an actual problem? If so, please create a new issue with a sample that demonstrates it and we can have a look.