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.

Sign up for GitHub

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

Jump to bottom

Avoid need for default constructor in ContextAnnotationAutowireCandidateResolver subclasses #25131

Closed
odrotbohm opened this issue May 26, 2020 · 1 comment
Closed

Avoid need for default constructor in ContextAnnotationAutowireCandidateResolver subclasses #25131

odrotbohm opened this issue May 26, 2020 · 1 comment
Assignees
@jhoeller
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone
5.2.7

Comments

@odrotbohm
Copy link
Member

As reported here, it seems that under certain circumstances, the BeanFactory expects ContextAnnotationAutowireCandidateResolvers to expose a default constructor which limits the ability to populate instances with configuration on construction.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label May 26, 2020
@jhoeller jhoeller changed the title ContextAnnotationAutowireCandidateResolver apparently needs default constructor Avoid need for default constructor in ContextAnnotationAutowireCandidateResolver subclasses May 26, 2020
@jhoeller jhoeller added in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels May 26, 2020
@jhoeller jhoeller self-assigned this May 26, 2020
@jhoeller jhoeller added this to the 5.2.7 milestone May 26, 2020
@jhoeller
Copy link
Contributor

This is coming from DefaultListableBeanFactory.copyConfigurationFrom for the special purpose of building internal copies of a given BeanFactory in certain scenarios. Replacing its AutowireCandidateResolver handling with a Cloneable arrangement instead of a hard BeanUtils.instantiateClass call seems to be a straightfoward and flexible enough solution here.

odrotbohm added a commit to spring-projects/spring-data-commons that referenced this issue May 26, 2020
@odrotbohm
DATACMNS-1734 - Defer initialization of Repositories in DomainClassCo…
4e8c731 
…nverter.

DomainClassConverter now delays the initialization of the Repositories instances used to avoid the premature initialization of repository instances as that can cause deadlocks if the infrastructure backing the repositories is initialized on a separate thread.

Refactored nested converter classes to allow them to be static ones.

Related issues: spring-projects/spring-boot#16230, spring-projects/spring-framework#25131.
mp911de pushed a commit to spring-projects/spring-data-commons that referenced this issue May 29, 2020
@odrotbohm @mp911de
DATACMNS-1734 - Defer initialization of Repositories in DomainClassCo…
95f069c 
…nverter.

DomainClassConverter now delays the initialization of the Repositories instances used to avoid the premature initialization of repository instances as that can cause deadlocks if the infrastructure backing the repositories is initialized on a separate thread.

Refactored nested converter classes to allow them to be static ones.

Related issues: spring-projects/spring-boot#16230, spring-projects/spring-framework#25131.
Original pull request: #445.
mp911de pushed a commit to spring-projects/spring-data-commons that referenced this issue May 29, 2020
@odrotbohm @mp911de
DATACMNS-1734 - Defer initialization of Repositories in DomainClassCo…
7af075f 
…nverter.

DomainClassConverter now delays the initialization of the Repositories instances used to avoid the premature initialization of repository instances as that can cause deadlocks if the infrastructure backing the repositories is initialized on a separate thread.

Refactored nested converter classes to allow them to be static ones.

Related issues: spring-projects/spring-boot#16230, spring-projects/spring-framework#25131.
Original pull request: #445.
mp911de pushed a commit to spring-projects/spring-data-commons that referenced this issue May 29, 2020
@odrotbohm @mp911de
DATACMNS-1734 - Defer initialization of Repositories in DomainClassCo…
3627030 
…nverter.

DomainClassConverter now delays the initialization of the Repositories instances used to avoid the premature initialization of repository instances as that can cause deadlocks if the infrastructure backing the repositories is initialized on a separate thread.

Refactored nested converter classes to allow them to be static ones.

Related issues: spring-projects/spring-boot#16230, spring-projects/spring-framework#25131.
Original pull request: #445.
mp911de pushed a commit to spring-projects/spring-data-commons that referenced this issue May 29, 2020
@odrotbohm @mp911de
DATACMNS-1734 - Defer initialization of Repositories in DomainClassCo…
210ab24 
…nverter.

DomainClassConverter now delays the initialization of the Repositories instances used to avoid the premature initialization of repository instances as that can cause deadlocks if the infrastructure backing the repositories is initialized on a separate thread.

Refactored nested converter classes to allow them to be static ones.

Related issues: spring-projects/spring-boot#16230, spring-projects/spring-framework#25131.
Original pull request: #445.
FelixFly pushed a commit to FelixFly/spring-framework that referenced this issue Aug 16, 2020
@jhoeller
Introduce AutowireCandidateResolver.cloneIfNecessary() method
9af670b 
Closes spring-projectsgh-25131
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jhoeller jhoeller

Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Milestone
5.2.7
Development

No branches or pull requests
3 participants
@odrotbohm @jhoeller @spring-projects-issues