You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
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
The text was updated successfully, but these errors were encountered: