-
Notifications
You must be signed in to change notification settings - Fork 37.8k
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
ConfigurationClass.validate() should allow for overloading in general or not at all [SPR-11025] #15653
Comments
Jose Luis Martin commented I have done a pull request to try to fix the issue. |
Jose Luis Martin commented Hi Phil, I think that the test BeanMethodPolymorphismTests is broken. It is not actually testing configuration classes overloaded methods as SubConfig doesn't extend SuperConfig
More in deep, I guess that inheritance in configuration class doesn't matter for overloaded methods. They are resolved as a plain class at all. The method used to instantiate the bean is ConstructorResolver.instantiateUsingFactoryMethod() which only takes into account inheritance when:
So I still think that validate() should test for overloaded methods from superclasses (or never test) I added both test cases to BeanMethodPolymorphismTests in chelu/SPR-11025/BeanMethodPolymorphismTests.java |
Juergen Hoeller commented I've removed that overloading check for 4.0 RC2 now. In combination with #15620, this means that we're generally supporting The only problem is where to pick the bean definition metadata from. We need to do this very early, without knowing which factory method is going to be picked for a particular scenario - since this is a dynamic choice and highly dependent on the available dependencies at the time of first creation of an instance. In an ideal world, we'd like to have exactly one source for each bean's metadata at any configuration class level. We could theoretically put that metadata at the type level, pointing to a factory method by name (similar to the XML bean definition scenario). However, that's not very practical. So as of #15620, we're always picking the metadata from the most concrete subclass. However, with overloading in mind, there may be several sources of metadata (i.e. several same-named methods) in every subclass. We're technically picking the So, to be clear for the practical impact, a bean's definition metadata may be overridden in a config subclass along with an overridden or overloaded Juergen |
Jose Luis Martin commented Great!. |
Jose Luis Martin opened SPR-11025 and commented
When checking for overloaded methods, ConfigurationClass.validate()
don't take in account overloaded methods from superclasses, so a invalid configuration class with overloaded methods obtained by inheritance bypass the check.
Affects: 4.0 M3
Issue Links:
@Bean
overriding does not pick up metadata from most specific method@Bean
method override regression with return type narrowing on JDK 8Referenced from: commits 935bd25
The text was updated successfully, but these errors were encountered: