Support for @Order on nested configuration classes [SPR-15384]

[spring-projects-issues]

Stefan Fussenegger opened SPR-15384 and commented

ConfigurationClassParser adds member classes in the order they are returned by the ASM-based MetadataReader and ClassMetadata while no further ordering seems to be applied.

Members are returned - at least in my setup - in alphabetical order by ASM. I couldn't find any documentation though that would suggest that this is the expected behavior. It simply seems to be the order in which ASM reads member names form the class file (so this might be even depending on the compiler?)

---

Affects: 4.3.7

Reference URL: spring-attic/spring-framework-issues#152

Issue Links:

• Deterministic and JVM-independent @Bean registration order within Class-reflected configuration classes [SPR-14505] #19074 Deterministic and JVM-independent @Bean registration order within Class-reflected configuration classes

Referenced from: commits spring-attic/spring-framework-issues@4928f52, spring-attic/spring-framework-issues@d447102

[spring-projects-issues]

Stefan Fussenegger commented

Added spring-framework-issues project PR

[spring-projects-issues]

Juergen Hoeller commented

Let's narrow the focus of this ticket to @Order support on nested configuration classes, effectively as a follow-up to #17257. We support order annotations on explicitly registered/scanned top-level configuration classes already, just not on nested ones... However, for nested classes, we can only really apply the order locally within the containing class since the are conceptually only a part of their containing configuration class.

As for the runtime order of member classes, this seems to be consistent between Java reflection and ASM-read bytecode at least: It is always alphabetical by class name for me.

[spring-projects-issues]

Juergen Hoeller commented

We locally support such nested configuration classes within their containing class now. Note that the order values are not "global" among all configuration classes but rather just matter for the local group of nested classes (as an alternative to the by-name default order) among themselves.