Failing context lookup/binding from MicronautApplicationContext.getBeansOfType

[frehov]

Expected Behavior

When using the application context to lookup beans of a certain type, I expect to get all beans associated with that type.

Actual Behaviour

1. When using the (micronaut-core) application context to lookup beans of a certain type, I get all beans associated with a certain type regardless of them having a named annotation or not.
2. When using the (micronaut-spring) application context to lookup beans of a certain type, I get a NoSuchBeanException if the bean I'm looking up is multiple named beans.

Steps To Reproduce

1. Create a ConfigurationProperty-class annotated with @EachProperty("a.b") and @Context the class should receive the named parameter in it's constructor
2. Create an ApplicationEventListener<StartupEvent> and inject both micronaut and spring application contexts
3. add properties a.b.a, a.b.b, a.b.c to application.yml
4. With the micronaut application context call micronautContext.getBeansOfType(Config.class) and get 3 configuration class beans.
5. With the spring adapted application context (MicronautApplicationContext class) call springContext.getBeansOfType(Config.class) and get a NoSuchBeanException with a message "No bean named 'Config(a)' available" (there might be a variation of either a, b or c as the name.)

Environment Information

• WIndows 10 - Latest update
• OpenJDK 16.
• Kotlin 1.5.31
• Gradle 7.2
• Micronaut-bom 3.2.1

Example Application

Demo Application

Version

3.2.1

[graemerocher]

Please provide an example that reproduces the problem

[frehov]

@graemerocher I've added an example in the original submisson, but for brewity here's the link https://github.com/frehov/micronaut-spring-failing-context-lookup-demo

The code doing the lookup through context is in the StartupListener class, I've also added a third example which is using the Spring BeanFactoryUtils

The exception thrown is NoSuchBeanDefinitionException and not NoSuchBeanException, I've also updated to micronaut 3.2.2, but the issue is present in 3.2.0 and 3.2.1 as well.