You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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):
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 theconstructorOrFactoryMethod
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.
The text was updated successfully, but these errors were encountered: