Add support for registering multiple init & destroy method names

[snicoll]

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.

[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.

[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?

[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.

[chenggwang]

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.

I didn't find any actual problems. I discovered during the use of Spring that a bean can have multiple initialization or destruction methods using either 'beanDefinition. SetInitMethodNames (init1, init2)' or 'beanDefinition. SetDestroyMethodNames (destruct1, destruct12)'. These methods were submitted by you three years ago. If only AOT is supported, should these methods be visible within the package so that they cannot be called externally? If bean multi initialization methods are supported, implement @ bean (initMethod={"init1", init2,... "}). Support multi initialization methods, I have modified the implementation locally and can submit the code.