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

GenericApplicationContext.registerBean should support non-default constructors [SPR-17292] #21825

Closed
spring-projects-issues opened this issue Sep 19, 2018 · 3 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 Sep 19, 2018

Juergen Hoeller opened SPR-17292 and commented

While AnnotationConfigApplicationContext.registerBean supports @Autowired resolution on constructors in case of no instance supplier given, the original method on GenericApplicationContext performs default instantiation only. Making GenericApplicationContext.registerBean smarter in detecting a Kotlin primary constructor or simple non-default public constructor scenarios makes it aligned with AnnotationConfigApplicationContext and more useful in general, in particular for Kotlin DSLs.


Issue Links:

Referenced from: commits 47d6e91, d3c0855

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Since full AUTOWIRE_CONSTRUCTOR exhaustively looks at all constructors (public, private, whatever), it does not seem like an ideal candidate here. Instead, a new "preferred constructors" mechanism allows registerBean to suggest the Kotlin primary constructor and standard public constructors to be evaluated for autowiring before falling back to default instantiation. This covers the intended use cases and is largely aligned with the constructor determination algorithm for model attribute processing.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Sébastien Deleuze, this should cover your intended use case in the Kotlin DSL now, with no need for a custom post-processor anymore.

@spring-projects-issues
Copy link
Collaborator Author

Sébastien Deleuze commented

Thanks, I have updated the Kotlin DSL accordingly.

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