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-issuemaster opened this issue Apr 13, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Apr 13, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 15, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 16, 2015

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
You can’t perform that action at this time.