Skip to content

Update AOT processing to account for multiple init or destroy methods #28151

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

Closed
snicoll opened this issue Mar 9, 2022 · 1 comment
Closed
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) theme: aot An issue related to Ahead-of-time processing type: enhancement A general enhancement
Milestone

Comments

@snicoll
Copy link
Member

snicoll commented Mar 9, 2022

Now that #28013 is implemented we need to make sure that the bean definition is registered with the appropriate init and destroy method names.

@snicoll snicoll added in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement theme: aot An issue related to Ahead-of-time processing labels Mar 9, 2022
@snicoll snicoll added this to the 6.0.0-M3 milestone Mar 9, 2022
@snicoll snicoll self-assigned this Mar 10, 2022
@snicoll snicoll added the status: blocked An issue that's blocked on an external project change label Mar 10, 2022
@snicoll
Copy link
Member Author

snicoll commented Mar 10, 2022

I am blocked. I've added AotContributingBeanPostProcessor to the BPP that detects custom init and destroy methods. I am now left with the choice of mutating the RootBeanDefinition. From an AOT perspective, that's alright as the bean instance supplier is generated first (and therefore the contributors are invoked upfront).

From a context perspective, it is a little bit odd as MergedDefinitionBeanPostProcessor explicitly states that the methods of the base BeanDefinition class couldn't be invoked.

Looking at things from a generic fashion, if MergedDefinitionBeanPostProcessor did register those using the API that was created as part of #28103, then this PP shouldn't even have to be an aot-contributing. It kind of shows in the current implementation where it mutates the RootBeanDefinition if necessary and always return a null contribution.

snicoll added a commit to snicoll/spring-framework that referenced this issue Mar 10, 2022
@snicoll snicoll removed the status: blocked An issue that's blocked on an external project change label Mar 12, 2022
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) theme: aot An issue related to Ahead-of-time processing type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant