With #29556, We've added a check in BeanDefinitionMethodGenerator to prevent processing a bean definition that has an instance supplier. The check was further refined to look if there is at least one contribution to tune how the registration happens.

The problem is that this check does not validate in any way that the instance supplier is taken care of. The custom code fragments could be about anything really, with the default behavior applying still for generating the code that creates the bean.

We should rather move the check to code fragments that are actually relying on the fact that the BeanDefinition provides the metadata to instantiate the bean, rather than an instance supplier that hides it. These are:

  • getTarget: as the constructorOrFactoryMethod is resolved and that doesn't make sense for a bean that's instantiated by an instance supplier.
  • generateInstanceSupplierCode obviously, as it takes care of generating the code to instantiate the bean.

Moving the check there makes sure that we will not skip cases where we should previously have thrown an exception.

Comment From: snicoll

This is visible, in particular, in this test that doesn't provide any customization for the code whatsoever (which means the core container will attempt to resolve the constructor to use and ignore the instance supplier altogether):

https://github.com/spring-projects/spring-framework/blob/66a571fe276eb49727b7d1bacc4da92548dd3573/spring-beans/src/test/java/org/springframework/beans/factory/aot/BeanDefinitionMethodGeneratorTests.java#L180