beanFactory#getBean with arguments ignore them if an Instance supplier is defined about spring-framework

[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.

[snicoll]

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

Yes and no. There was definitely a bug that we used an instance supplier even in the case getBean was used with custom arguments. So I fixed that but the whole thing is a bit strange with AOT/native.

The instance supplier is used to apply the optimizations we've discovered at build-time. Typically, the autowiring on the field in CommandExample is processed there, rather than discovering things at runtime. The pattern you've used means that you'd like to instantiate the bean in a custom manner. This has two consequences:

1. We don't know the constructor you're going to invoke as the arguments are in your own code with no way to discover them. As such, the sample with this fix would not work until you add some reflection hint for the constructor that takes the Integer argument.
2. Now that the instance supplier is discarded, the autowiring is no longer applied and that field is null.

Looking at your simplified example, I wonder if CommandExample has to be a bean. IMO it would be better to provide the service and the integer to the constructor, and resolve the service in your controller. I am sure your actual code is more involved but not making it the command a bean is something you should be pursuing for native compatibility. In particular, getBean with arguments is not recommended. I've created #32690 to document that bit.