Now that #28013 is implemented we need to make sure that the bean definition is registered with the appropriate init and destroy method names.
Comment From: snicoll
I am blocked. I've added AotContributingBeanPostProcessor
to the BPP that detects custom init and destroy methods. I am now left with the choice of mutating the RootBeanDefinition
. From an AOT perspective, that's alright as the bean instance supplier is generated first (and therefore the contributors are invoked upfront).
From a context perspective, it is a little bit odd as MergedDefinitionBeanPostProcessor
explicitly states that the methods of the base BeanDefinition
class couldn't be invoked.
Looking at things from a generic fashion, if MergedDefinitionBeanPostProcessor
did register those using the API that was created as part of #28103, then this PP shouldn't even have to be an aot-contributing. It kind of shows in the current implementation where it mutates the RootBeanDefinition
if necessary and always return a null
contribution.