Description
See #30900 for an example.
When crafting a BeanDefinition
for a class with multiple constructors and AUTOWIRE_CONSTRUCTOR
mode, the regular runtime chooses the "most suitable" constructor based on the available beans in the BeanFactory
. Arguably this is a behavior that can be a bit surprising and can be expressed in a much better way using Optional
or ObjectProvider
for the constructor arguments that may or may not be present.
AOT does not support this algorithm and we're not keen to change that as we're considering deprecating and removing the capability of choosing the constructor based on available dependencies. However, for existing use cases, users have no other choice than refactoring their code, such as adding @Autowired
on the preferred constructor, or changing the signature to use Optional
or ObjectProvider
. This issue is about offering an escape hatch, for instance adding an attribute at the bean definition level that ConstructorResolver
would use to pick up the preferred constructor.