Juergen Hoeller opened SPR-11521 and commented
In Spring Framework 4.0, we take the factory method return type into account for injection targets (i.e. the right-hand side of an assignment) but not for injection points themselves (i.e. the left-hand side). As a consequence, type variables in @Autowired fields or method parameters are not getting resolved if the only place where they are being substituted is the return declaration of the factory method that creates the containing object. See the provided test scenario for #16096 for an example.
We should revisit this for 4.1, introspecting the factory method return type if the containing class itself doesn't substitute the type variable anywhere in its hierarchy.
Affects: 4.0.2
Issue Links: - #16096 Autowiring unable to find generic dependency in case of nested unresolved type variable - #15303 Inferring an ApplicationListener's event type from a lambda or method reference - #16105 getBeanNamesForType should consider FactoryBean generics for early introspection of config classes as well - #19726 Collection autowiring does not resolve field-level type variable against containing class
Comment From: jhoeller
There are no plans to revisit this issue since there has not been any activity. Arguably, from a Java design perspective, such type variables simply remain unsubstituted in any case. The common solution is to define subclasses that actually substitute the type variables, and then to return those subclasses from the factory methods.