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-issuemaster opened this issue Sep 19, 2018 · 3 comments

Comments

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

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:

  • #21775 Bean definition DSL does not generate unique bean names
  • #21808 Expose more AbstractBeanDefinition methods in BeanDefinition
  • #20569 Streamline and reduce Kotlin delegates

Referenced from: commits 47d6e91, d3c0855

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 19, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 19, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 19, 2018

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