Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Nov 30, 2015 · 10 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Nov 30, 2015

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:

  • #19178 Avoid creation of lazy candidates when the primary bean is injected

Backported to: 4.1.9, 3.2.16

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 30, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 30, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 30, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 1, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 2, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 2, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 2, 2015

Jakub Bochenski commented

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 3, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 5, 2015

Jakub Bochenski commented

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 6, 2015

Juergen Hoeller commented

Great to hear - thanks for the timely feedback!

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants