Problem with autowiring of "generic Beans" (defined via RootBeanDefinition(s)) [SPR-11250]

[spring-projects-issues]

Burkhard Graves opened SPR-11250 and commented

Hello everybody,

I would like to point out a problem which i already described here and here.

I've attached a simple maven project containing a test which succeeds in Spring-3 but fails in Spring-4. In short: Beans defined ex. via RootBeanDefinition(s) can't be autowired if

<context:annotation-config/>

is used. If using a AutowiredAnnotationBeanPostProcessor only, the problem disappears.

I guess it's due to the changes in AnnotationConfigUtils#registerAnnotationConfigProcessors().

Any ideas, hints?

Regards,
Burkhard

---

Affects: 4.0 GA

Attachments:

• spring4.zip (3.83 kB)

Issue Links:

• Upgrading spring from 3.2 to 4 - Issue with generics (extends) [SPR-11382] #16009 Upgrading spring from 3.2 to 4 - Issue with generics (extends)
• ResolvableType.isAssignableFrom() failure for raw types [SPR-11414] #16041 ResolvableType.isAssignableFrom() failure for raw types
• DATACMNS-424 Injection of PagedResourcesAssembler fails on Spring 4.0.1 snapshots

0 votes, 7 watchers

[spring-projects-issues]

Juergen Hoeller commented

This seems to be a problem with our GenericTypeAwareAutowireCandidateResolver, a base class of ContextAnnotationAutowireCandidateResolver which in turn is being set in AnnotationConfigUtils.

This GenericTypeAwareAutowireCandidateResolver in 4.0 is capable of doing fine-grained matching between generic type declarations at the injection point and corresponding target classes, avoiding the need for qualifiers if the generic type information is sufficiently expressive.

However, it comes with the potential for side effects in case of incomplete generic matches: like your scenario where the injection points declare a specific type whereas the target class leaves the type variable unresolved, relying on a plain match by primary object type.

We'll sort this out for 4.0.1, making your scenario accepted as an autowire candidate as well. We have a mechanism for this in place already; it just doesn't seem to do its job in your specific case...

Juergen

[spring-projects-issues]

Burkhard Graves commented

Thanks for your quick response!

Is it possible (or will it eventually be possible) to describe generic type informations by RootBeanDefinitions?

If not, are there other ways to create "generic beans" dynamically?

--Burkhard

[spring-projects-issues]

Juergen Hoeller commented

It shouldn't be necessary to manually describe the type information; we should be able to reason about it properly based on the classes themselves. This is definitely a bug in our matching algorithm here.

The root of the problem in your scenario seems to be the bounded type (T extends Number): If you change it to just a plain type variable (T), our algorithm seems to kick in properly. So we just need to handle that bounded type case properly, considering it as "unresolved" and hence allowing fallback matches based on the primary object type.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Fixed for 4.0.1 through a revision of our hasUnresolvableGenerics() algorithm, being able to deal with bounded unresolvable variables as well now.

Feel free to give the next 4.0.1 snapshot a try (see http://projects.spring.io/spring-framework/ for repo details...

Juergen

[spring-projects-issues]

Burkhard Graves commented

Ok, great, but: If I change the beanName in

bd = new RootBeanDefinition(NumberStore.class);
ctx.registerBeanDefinition("doubleStore", bd);

from "doubleStore" to "whatEver", the following exception occurs:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'test.Bean#0': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private test.NumberStore test.Bean.doubleStore; nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [test.NumberStore] is defined: expected single matching bean but found 2: whatEver,floatStore
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:967)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:855)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:480)
	at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:87)
[...]

-> So it looks as if the beanName is used to resolve the matching bean?!

That's why I asked

Is it possible (or will it eventually be possible) to describe generic type informations by RootBeanDefinitions?

How can I "tell" spring, that the bean "whatEver" stores Doubles (instead of Float or something else) such that it can (and should) be autowired to

@Autowired
private NumberStore<Double> doubleStore;

???

I hope the stuff I'm writing is understandable - we've just drunk some "Glühwein" (mulled wine?! - google translate) in our office... ;-)

--Burkhard

[spring-projects-issues]

Juergen Hoeller commented

Indeed, it it using the bean name as a kind-of "fallback" qualifier there. At least the type is now considered a match, so the bean name matching is allowed to happen - which is certainly an improvement already, and brings Spring 4.0 in line with 3.2.5, fixing that regression.

Your point with different bean names is of course valid but didn't work in 3.2.5 either, so at least there's no regression there. I would nevertheless suggest to rely on the bean name convention, or to associate specific @Qualifier annotations with both the injection points and the target beans. Other than that, you can also simply make the target bean declare the type variable specifically. It'd be a bit odd to add that information to the bean metadata, frankly; either it's expressed in the target class itself (e.g. subclassing NumberStore accordingly), or you'll have to establish the relationships through the general qualifier mechanism, just like in other cases of ambiguity.

Juergen

[spring-projects-issues]

Burkhard Graves commented

Thanks for all the details!

Short explanation of my motivation: We have some project with a base class B which is extended by lots of other beans B'. These beans are annotated and registered as spring beans by classpath scanning. There's also a base class S<T extends B> and for each bean B' some -bean S' extending- instance S' of S<B'> is configured and registered dynamically via RootBeanDefinitions - lots of beans B', lots of beans S' with "corresponding" names.

Everything works fine by relying on the bean name convention you mentioned. I just hoped for something "better" when I heard about the new shiny Spring 4.0 features.

But, as I said, everything works fine and I understand your arguments.

Thanks again!
Burkhard

[spring-projects-issues]

Torsten Krah commented

How can this generic type be specified with classical files based xml declaration?

I don't want to subclass "my" generic base class to just have the concrete type for autowiring available and using qualifiers won't help much either - i want use type based injection.

How can i make "concrete" xml declarations of a generics prototype bean in xml and add the "type" there, for which it should be found when ask as autowire candidate?

Example:

bean definitions:

new ??:

<bean class="java.util.List<MyObject>" scope="prototype" />
<bean class="java.util.List<MyObject2>" scope="prototype" />

old (Spring 3):

<bean class="java.util.List" scope="prototype" />

target class:

class X {

@Autowired
List<MyObject1> myInstance;
@Autowired
List<MyObject2> myInstance2;

}

[spring-projects-issues]

Stéphane Nicoll commented

I am confused by your example. @Autowired on lists collects all beans of the specified type and injects them so all you should do in your example is register the beans for MyObject1 and MyObject2 and that should work automatically. And this already work prior to 4.0.

If I misunderstood your example, then I believe Juergen has already explained why qualifiers are important in such a case: beans are registered against their type signature. If your base class (Foo) has a generic type, the generic type is part of the signature so you can't resolve that type in the bean definition (as shown by your example).

In summary, qualifier in your case is the way to go and this is not new as Juergen already explained. Please let me know if I missed anything.

[spring-projects-issues]

Burkhard Graves commented

With regard to my example, I think Torsten (and I) would like to write something like

<bean class="test.NumberStore<Double>" />
<bean class="test.NumberStore<Float>" />

hoping that

@Autowired
private NumberStore<Double> doubleStore;

@Autowired
private NumberStore<Float> floatStore;

can be autowired by type.

Instead we should / have to use

<bean id="doubleStore" class="test.NumberStore" />
<bean id="floatStore" class="test.NumberStore" />

@Autowired
@Qualifier("doubleStore")
private NumberStore<Double> doubleStore;

@Autowired
@Qualifier("floatStore")
private NumberStore<Float> floatStore;

which looks "not so nice"... ;-)

Edit: Ok, may be the qualifiers can be left out due to the discussed naming convention fallback...

[spring-projects-issues]

Torsten Krah commented

Burkhard got it - thats what i wanted to express with my List example.
Spring let you the choice to use xml based, annotation based or the new java based configuration or combine them, if you want to.

But this generic types feature is not usable for the moment with xml based declaration and using type based injection like in Spring 3 - where it was not checked but did work for autowiring - no need for qualifiers.

So the only question remains - like Burkhard wrote in his first example above - how to declare this in xml files, without qualifiers (the naming fallback is not that nice and easily missed, types are imho better) - we got types already which are enough, but no way to express it in the xml file.

[spring-projects-issues]

Juergen Hoeller commented

My main concern at this point is a potential regression: Do you have working configuration in Spring 3.x that doesn't work against a recent Spring 4.0.1 snapshot anymore, without any changes to your files? A plain untyped bean should get used as a fallback match in Spring 4.0.1, so I wonder whether that part actually works...

As for specifying generic type declarations in XML bean class names, let's consider that as a separate JIRA issue since it is an enhancement request and not a bug... I'd like to keep this one focused on regressions in the generic type matching algorithm.

Juergen

[spring-projects-issues]

Torsten Krah commented

• edit -- Investigating, test project does work with actual 4.0.1.BUILD-SNAPSHOT, going to revert changes on living object and see if snapshot fixes the problem - maybe some errors appeared because of refactoring stuff because of this change where 4.0.0 failed before we noticed this jira issue, keeping you informed if this is done or still needs some work asap.

[spring-projects-issues]

Juergen Hoeller commented

Any update, Torsten? Note that the 4.0.1 release is coming in a week's time, so we still have a chance to follow up if any problems remain...

Juergen

[spring-projects-issues]

Burkhard Graves commented

On my side everything runs fine with 4.0.1.BUILD-SNAPSHOT.

As for specifying generic type declarations in XML bean class names ...

... and RootBeanDefinitions ;-)

..., let's consider that as a separate JIRA issue since it is an enhancement request and not a bug...

+1