beanFactory#getBean with arguments ignore them if an Instance supplier is defined

[antonioiorfino]

When use a BeanFactory inside my project I have two different result for the same operation after standard build and native build.
The different behavior is related to prototype's scope bean when use the following methods:

• beanFactory.getBean(Class requiredType, Object... args)
• beanFactory.autowireBean(Object existingBean)
• beanFactory.initializeBean(Object existingBean, String beanName)

I have created a simple project in order to explain better my problem spring-boot-test.
It is based on spring-boot 3.2.4 with GraalVM

Java version: 17.0.11, vendor: Oracle Corporation

I didn't seen something on documentation, I hope it is my mistake.

Command Pattern

When call the api http://localhost:8080/test/1 the expectation is to set the value "1" using the CommandExample constructor. This approach it works on standard build, with native the beanFactory will create a prototype using always the empty constructor. The result is the command not have any data to proceed with the elaboration.

Initialization Bean

When call the api http://localhost:8080/instance the expectation is to instantiate a BeanInstanceExample class programmatically during the initialization of the ServiceBeanInstanceExample.
Also in this case the initialization of the BeanInstanceExample with the autowireBean and initializeBean works fine with the standard build, but not work in a native build.

I hope everything is clear

[snicoll]

Thanks for the report. I can see that the BeanFactory indeed calls the default constructor of CommandExample albeit being provided with the integer argument.

The resolution of the constructor is highly dynamic and AOT cannot detect this pattern at build time. I had hoped that providing the necessary reflection hints would fix it but it does not work and will need some further investigation.

[snicoll]

So it turns out that the code path of this method does not ignore an instance supplier if one is defined. This explains why the default constructor is invoked albeit a matching argument being provided.

Please note that creating a bean like this is not idiomatic Spring and we won't be able to infer the necessary hints as we can't detect at build time that this constructor is going to be invoked by reflection.