With reference to https://github.com/spring-projects/spring-boot/issues/40234#issuecomment-2051457742, 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)
Comment From: 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).
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: jhoeller
This works fine for me with a new DependencyDescriptor constructor taking a name String and the type as ResolvableType, to be passed into the existing resolveDependency method. It's an entirely local change in the descriptor classes, not touching the container or the resolution algorithm at all.
Comment From: wilkinsona
Thanks for looking at this Juergen. After refreshing my memory of https://github.com/spring-projects/spring-boot/issues/40234 , the driver for this was in support of Spring Boot's @MockBean and @SpyBean support. With the move to replacing that with Framework's @MockitoBean and @MockitoSpyBean in Framework 6.2 (Boot 3.4), Boot's need has largely gone, particularly as the fix that we eventually came up with for 40234 has thus far proven to be quite robust.
As things stand, unless there's a need for this from elsewhere, I don't think I'd change anything here at the moment. This one could perhaps even just be closed. We can always re-open it if the need arises again in the future.
Comment From: jhoeller
Alright, I'll leave it at the present state then. While my proof of concept seems to work fine, it requires a couple of additional constructors on InjectionPoint and DependencyDescriptor where I'm not sure how far to go (dependency name, Class vs ResolvableType, annotations) - so I'd rather no go there if there is no concrete need at this point.