Type-based bean name resolution with fallback matching for incomplete generics

[wilkinsona]

With reference to spring-projects/spring-boot#40234 (comment), it would be very useful if DefaultListableBeanFactory automatically considered the target type of a factory bean's definition when determining the type that it will produce. This would complement the existing support for checking the FactoryBean.OBJECT_TYPE_ATTRIBUTE on the definition. From Boot's perspective, the end goal is to improve the matching of beanFactory.getBeanNamesForType(resolvableType, true, false)

[jhoeller]

@wilkinsona for 6.1.7, is there anything you'd expect the core container to do here specifically, beyond the general target type support that it has already? I'm afraid there is not much we can do about mismatches between wildcard target types and specific generics requested, as in the Spring Data scenario - with getBeanNamesForType(ResolvableType), that is. Fallback matches only kick in for resolveDependency, as discusssed, where the starting point is getBeanNamesForType(Class).

[wilkinsona]

Given that fallback matching only kicks in for resolveDependency (that, as discussed elsewhere, we can't easily use as we may not have a field or method parameter to back the dependency), I'm not sure that there is in a maintenance release. I'd welcome an API that essentially combines getBeanNamesForType and resolveDependency so that a single method call can give us the full answer including fallback matching but I suspect that's too much for 6.1.x.

[jhoeller]

To summarize our current understanding here: The best we have on offer at the moment is resolveNamedBean(Class) as an alternative to DependencyDescriptor-based resolveDependency for whenever there is just a Class available, or to perform getBeanNamesForType(Class) and mimic the dependency resolution on top of that.

Addressing such a scenario with a first-class entry point is certainly rather a 6.2 topic.