If the beanClass attribute of a bean definition is configured, it should be considered when scanning for necessary reflection information, ultimately ending up in reflect-config.json. Currently, code that sets this attribute on a bean definition has to manually register the required property backing methods for reflection.
Comment From: snicoll
Use case is beanClass refers to a FactoryBean and resolvedTargetType to the bean that it produces. Right now our API assumes that getResolvedTargetType is the only candidate but factory beans-based scenario are a bit more complicated than that.
Comment From: snicoll
ConstructorOrFactoryMethodResolver which was copied over from Spring Native is able to identify that a BeanDefinition has a FactoryBean beanClass that is compatible with the resolvedTargetType set on the bean definition.
As a result, the proper instance supplier is generated.
However BeanDefinitionPropertiesCodeGenerator#addPropertyValues uses beanDefinition.getResolvableType() as the source for the property. If a matching method is not found, then no hint is added.
It would be nice if we had a way to connect those two so that they are consistent.