Reference manual - document interactions / ordering when using multiple styles of bean lifecycle [SPR-3775]

[spring-projects-issues]

Chris Lee opened SPR-3775 and commented

There are three styles for controlling bean lifecycle behaviour: InitializingBean/DisposableBean, bean methods names, and (new in 2.1) @PostConstruct and @PreDestroy.

The reference manual should document what happens when you 'mix' these options, specifically any side-effects and the order of applicability.

A use-case for this would be concrete inheritance - take, for example, DaoSupport which implements InitializingBean. It may well be that, on a given project, Spring is configured to call an init() method by default. What happens when a subclass of DaoSupport is initialized? In what order are afterPropertiesSet() and init() called? Any side-effects, recommendations, or warnings?

---

Affects: 2.0.6, 2.1 M3

[spring-projects-issues]

Chris Lee commented

From a brief glance through the source, the order would appear to be:

CommonAnnotationBeanPostProcessor
InitializingBean
init methods

...and presumably the reverse on destruction.

[spring-projects-issues]

Juergen Hoeller commented

It is actually the same order on destruction: first post-processors, then DisposableBean, then a destroy-method.

In any case, this needs to be mentioned in the reference docs.

Juergen

[spring-projects-issues]

Sam Brannen commented

Hi Chris,

Thanks for pointing out this missing information.

As a result, I've added a new section (i.e., "Combining lifecycle mechanisms")
in chapter 3 of the reference manual addressing this issue. Have a look in one
of the upcoming nightly snapshots for 2.5 RC1.

In addition, thanks to your inquiry, I discovered a 'bug' in which methods annotated
with JSR 250's @PostCreate or @PreDestroy were being executed twice if the
same method name was configured via one of the other lifecycle mechanisms.
FYI: Juergen has already fixed it for us. ;)

Regards,

Sam

[spring-projects-issues]

Chris Lee commented

Thanks Sam, that nicely clarifies this.