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 discussed, 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.

[jhoeller]

@wilkinsona I've experimented with this a bit, and semantically you are arguably asking for resolveDependency - just without a field or method parameter to back it. Would it help to build a DependendyDescriptor with a given ResolvableType (plus possibly a dependency name String but without a field or method handle) and nevertheless call the regular resolveDependency method for your purposes?

If you wanted to try that approach, you could even currently instantiate an inline subclass of DependendyDescriptor with any fake field and override getDependencyType() and getResolvableType() with the type that you are actually looking for... that seems to work without any container changes for some scenarios that I've sketched, going into a fallback match for the provided type as intended.