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

support non-lenient constructor injection [SPR-5816] #10486

Closed
spring-projects-issues opened this issue Jun 9, 2009 · 2 comments
Closed

support non-lenient constructor injection [SPR-5816] #10486

spring-projects-issues opened this issue Jun 9, 2009 · 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

spring-projects-issues commented Jun 9, 2009

Costin Leau opened SPR-5816 and commented

Currently, for constructor injection the container assumes a default type of String for values injected. Consider the following class:

Foo(String s) {}
Foo(Boolean b) {}
<bean class="Foo">
<constructor-arg value="true"/>
</bean>

Currently Spring will pick the first (String) constructor - arguably the second one is also valid. It would be useful to have a flag or some means (even programatically) to change this behaviour so when more then one constructor are found suitable, an exception is raised.


Affects: 3.0 M3

Issue Links:

Referenced from: commits 8e27971, a9254b3

@spring-projects-issues
Copy link
Collaborator Author

Costin Leau commented

Based on our discussion, this could be implemented (in a backwards compatible way) by taking into account the defaultType of the TypedStringValue. By default this would be set to java.lang.String (for compatibility reason) but implementations could just change it into null or maybe java.lang.Object which prevent any String assignment from happening.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Introduced "lenientConstructorResolution" flag at the BeanDefinition level, as discussed.

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