Avoid scoped destruction callbacks in case of no post-processor actually applying [SPR-13744]

[spring-projects-issues]

Juergen Hoeller opened SPR-13744 and commented

As indicated by #18312 and encountered in other recent scoping scenarios, Spring creates destruction callbacks for every bean in a custom scope in many scenarios, due to DestructionAwareBeanPostProcessor implementations being registered in many common ApplicationContexts these days.

We should try to come up with a mechanism that allows us to skip such scoped a destruction callback if no post-processor actually applies to a given bean. This may require a SmartDestructionAwareBeanPostProcessor interface with a new callback which indicates whether postProcessBeforeDestruction would perform any concrete work for a given bean.

---

Affects: 4.2.3

Issue Links:

• Doc: Scope.registerDestructionCallback may get called for inner beans [SPR-13739] #18312 Doc: Scope.registerDestructionCallback may get called for inner beans
• Inner bean behind BeanFactoryPostProcessor should be able to receive application events [SPR-14783] #19349 Inner bean behind BeanFactoryPostProcessor should be able to receive application events
• ApplicationListenerDetector should prevent serialization of its ApplicationContext reference [SPR-14214] #18788 ApplicationListenerDetector should prevent serialization of its ApplicationContext reference

Referenced from: commits 2e6eb61, fca5365

[spring-projects-issues]

Juergen Hoeller commented

A SmartDestructionAwareBeanPostProcessor subinterface with a requiresDestruction(bean) method seems to do the job here. All our existing destruction-aware post-processors can naturally implement such a method, and AbstractBeanFactory simply checks it upfront before deciding to register a destruction callback, just like it checks for a destroy method definition upfront already.

Juergen