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

@Configuration enhancer does not throw proper exception in case of mismatched @Bean method [SPR-12905] #17504

Closed
spring-projects-issues opened this issue Apr 13, 2015 · 2 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Christopher Smith opened SPR-12905 and commented

Given two unrelated @Configuration classes, one of which (FooConfiguration) provides @Bean Foo fooBean() and the other which (BarConfiguration) provides @Bean Bar fooBean() and has another bean method that calls fooBean(), the CGLib enhancer will fill in the Foo fooBean from the first configuration, causing a ClassCastException trying to cast Foo to Bar. This is something of a bug on the user's side for having a name collision, but if the container can't handle duplicate names, it needs to report that error explicitly.


Affects: 4.1.6

Referenced from: commits e403aef, aa49949

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

This happens due to the container's override behavior: In such a scenario, @Bean Bar forBean() overrides @Bean Foo fooBean, with the Bar variant being the one registered with the container eventually. However, since you have another method programmatically calling the Foo variant on the first configuration class, the enhancer tries to redirect back to the container (as it should for any such @Bean method call) where it ends up delegating to the Bar variant registered there...

Effectively, such overriding is supported even in such a scenario, but only if the overriding bean is assignable to the original @Bean return type. So what we're arguably doing wrong here is that we're not throwing a proper exception; I'll try to address that.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

I'll turn this into a 4.2-only feature since we've already had a minor regression - easy enough to fix, but any such assertion has a potential of breaking somebody's scenario. Arguably not worth the risk for 4.1.7.

Juergen

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: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants