BeanFactoryAnnotationUtils.qualifiedBeanOfType should not instantiate all beans of given type before checking qualifier [SPR-13741]

[spring-projects-issues]

Jakub Bochenski opened SPR-13741 and commented

Basically what was reported on SO

Offending line: ```
Map<String, T> candidateBeans = BeanFactoryUtils.beansOfTypeIncludingAncestors(bf, beanType);

---

Affects: 3.2.15, 4.1.8, 4.2.3

Reference URL: https://stackoverflow.com/questions/27177364/spring-candidate-bean-type-strategy-is-bad

Issue Links:

• Avoid creation of lazy candidates when the primary bean is injected [SPR-14611] #19178 Avoid creation of lazy candidates when the primary bean is injected

Backported to: 4.1.9, 3.2.16

[spring-projects-issues]

Juergen Hoeller commented

Good point: This is an unfortunate assumption in BeanFactoryAnnotationUtils - used for specific lookup purposes in several places - which makes it only really work against a set of pre-initialized singletons of the given type. However, this is certainly the common scenario that said code has been designed for, so I'm turning this into an improvement request for BeanFactoryAnnotationUtils to work against lazy singleton beans or non-singleton beans as well (without unnecessary instantiation in such scenarios).

Juergen

[spring-projects-issues]

Jakub Bochenski commented

Thanks - that was fast reaction.

Actually I've run into this when using a custom (multiton-type) scope bean, so hopefully the planned patch will address this case too? (Just ensuring " non-singleton" doesn't really mean "prototype" :))

[spring-projects-issues]

Juergen Hoeller commented

I can confirm that non-singletons means prototypes as well as beans in custom scopes :-)

The fix is simply to use iteration via beanNamesForTypeIncludingAncestors, only calling getBean on the eventually selected bean. Since the fix is so straightforward and the improvement can be rather important in such scenarios, I'll backport it to 4.1.9 as well.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Jakub Bochenski, could you please give a recent 4.2.4.BUILD-SNAPSHOT a try and let me know whether it works for you? The release is still two weeks away but I'd be great to verify upfront.

Juergen

[spring-projects-issues]

Jakub Bochenski commented

TBH the application I got this problem with is still stuck with Spring 3.x -- I'll be trying to backport this and let you know soon

[spring-projects-issues]

Juergen Hoeller commented

Actually, I've considered backporting this to 3.2.16 already. I can do this later today, so the change will be available in a 3.2.16.BUILD-SNAPSHOT to try tonight.

Juergen

[spring-projects-issues]

Jakub Bochenski commented

Wow, I wish all OSS projects had such snappy support (cough maven cough)

[spring-projects-issues]

Juergen Hoeller commented

Today's 3.2.16.BUILD-SNAPSHOT contains this change in the meantime. Feel free to give it a try...

Juergen

[spring-projects-issues]

Jakub Bochenski commented

Confirmed against 3.2.16.BUILD-20151203.121416-6 -- working as expected

[spring-projects-issues]

Juergen Hoeller commented

Great to hear - thanks for the timely feedback!

Juergen