Beans resulting from by @EachBean transformation do not preserve @Order

[sdedic]

Expected Behavior

Beans produced by @EachBean based on a certain Bean should maintain the original's Bean @Order attribute, if defined. BeanDefinitionDelegate does not delegate getOrder() to its originating Bean.
For example, a Jdbi instance created over a DataSource which is @Order(-1000) does not report the same order and so if there are more DataSources, the implied Jdbi beans cause ambiguity on injection

Actual Behaviour

All Beans implied by @EachBean should maintain the original's bean @Order.

Steps To Reproduce

1. Build the example application from the repository, run the test, observe the failure

Detailed information:

I have a configuration-defined DataSource in my application. Currently using legacy dropwizard structure of configurations with includes, the datasource is defined at a more base level. There's no way how I can replace the @Named("default") DataSource, as it is @Primary at the same time. If I declare a @Bean in my test that produces @Primary data source, the test will throw on initialization because there are two @Primary beans the other comes from @EachProperty iterating over datasources.* which assigns the object resulting from .default subtree as @Primary.
Last, I've tried to @Order this test implementation to give it a priority - but the dynamic registration of EachProperty or EachBean does not delegate to the original bean definition's Order attribute, so even this way how to prioritize testing DataSource fails.

I suggest to

1. enhance the implied BeanDefinitionDelegate to delegate getOrder() to its delegate's value. This could be beneficial even for other cases, where wrappers or derivative beans are created, since they would maintain their original's priorities.
2. @EachProperty could be enhanced with "enabled" attribute to look for an explicit enabled sub-property (default name "enabled", default value: true). This luckily works specifically in DataSourceConfiguration so I used that as a workaround
3. The @Property annotation on tests could support removing of property subtree - e.g. remove attribute exclusive with value. In my case the test could erase specific datasource's configuration.

Maybe suggestions (2) and (3) should be filed as separate enhancement requests ?

Environment Information

• Ubuntu Linux 22.04
• Oracle JDK 21

Example Application

https://github.com/sdedic/micronaut-eachbean-bug

Version

4.6.0 4.6.5

[graemerocher]

sound like good suggestions but should each be a separate PR yes