This repository has been archived by the owner on Feb 23, 2023. It is now read-only.
Handle destroy callback #1048
Comments
Closed
Closed
|
Repurposing this issue to handle destroy callbacks as init callbacks are taken care of as part of #1059 |
Closed
snicoll
added a commit
that referenced
this issue
Sep 27, 2021
This commit rework the original proposal by writing the init and destroy methods and using them to instantiate a dedicated bean post processor that is similar to the original one used at runtime. Both method names defined on the bean definition itself as well as externally managed ones are supported. If the bean name is '(inferred)' similar logic is applied at build time. Closes gh-1048 See gh-1059
|
Fixed by 1f96ae9 |
snicoll
added a commit
that referenced
this issue
Sep 28, 2021
This commit rework the original proposal by writing the init and destroy methods and using them to instantiate a dedicated bean post processor that is similar to the original one used at runtime. Both method names defined on the bean definition itself as well as externally managed ones are supported. If the bean name is '(inferred)' similar logic is applied at build time. Closes gh-1048 See gh-1059
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
CommonAnnotationBeanPostProcessoris not invoked as we disable it when running in AOT mode. We should scan forPostConstructandPreDestroyand update the bean definition metadata accordingly.We're currently not writing that information so we should do that as well so that the container can pick it up. Since it's called via reflection, we'll have to update the native configuration for that as well.
The text was updated successfully, but these errors were encountered: