InitDestroyAnnotationBeanPostProcessor is flipping the initialization order [SPR-6344]

[spring-projects-issues]

Kenny MacLeod opened SPR-6344 and commented

As of RC1, the order in which bean init methods are being executed has been reversed, compared to the behaviour in 2.5.6 and M4.

Specifically, InitDestroyAnnotationBeanPostProcessor.LifecycleMetadata.addInitMethod is now adding each successive init method to the front of the list. Prior versions added it to the end.

This manifests itself as a problem in code where there are multiple init methods (e.g. multiple @PostConstruct methods) in one class. We have code where we're relying on those methods being executed in order, as returned by the reflection API. If there's executed in reverse order, it all breaks.

Is there a reason these methods are being explicitly reversed?

---

Affects: 3.0 RC1, 3.0 RC2

Referenced from: commits 3b9605b

[spring-projects-issues]

Kenny MacLeod commented

Happens with RC2 also.

[spring-projects-issues]

Juergen Hoeller commented

We're processing init methods top down now: base class first, then sub class, etc - and at each hierarchy level, we're processing them in the order of declaration. For destroy methods, it's the same but going through the hierarchy bottom up.

In previous 3.0 milestones, we tried to do proper init method hierarchy traversal from top down (which we didn't do before, always going bottom up in 2.5) but accidentally also reversed the order at each hierarchy level. This should be fixed in trunk now.

Juergen