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

autowiring by type does not take into account parent context [SPR-8] #4743

Closed
spring-projects-issues opened this issue Dec 14, 2003 · 3 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Jacques Morel opened SPR-8 and commented

Context:
Simple java app (not J2EE): IntelliJ IDEA plugin.
This app uses a third party container (propriatery not J2EE) that needs to be bridged into Spring. I use the strategy of creating a StaticApplicationContext to load all singletons created by the third party container and passing it as the parent of my own XML application context.

Problem:
I want to autowire all my beans. Some of my beans refer to beans defined in the StaticApplicationContext. Everything is fine if I use autowiring by name. However the autowiring by type does not work since it doesn't take into account the parent factory.


Affects: 1.0 M3

Attachments:

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Thanks for the report! I wasn't aware that this didn't work, and it was not covered by the test suite. I've fixed the lookup for matching beans in DefaultListableBeanFactory, and added a corresponding unit test.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Fixed in CVS, to be available in 1.0 M4.

@spring-projects-issues
Copy link
Collaborator Author

Jacques Morel commented

Just perusing the code I believe getBeanOfType and getBeanDefinitions still do not check for ancestors. Is that intended? Maybe they could accept a flag to make that switchable if you want to regain the old behavior.
My rational is that if getBean does check for ancestors beans it would be very surprising for me for the other 2 public methods not to do so.

Just my 2 cents obviously

BTW I am amazed by your turn around. Great job Juergen!

@spring-projects-issues spring-projects-issues added type: bug A general bug in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 10, 2019
@spring-projects-issues spring-projects-issues added this to the 1.0 M4 milestone Jan 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants