This repository has been archived by the owner on Feb 23, 2023. It is now read-only.
Invoke BeanDefinitionRegistryPostProcessors at build time #1213
Comments
snicoll
changed the title
|
That's only calling the BDRPP that are registered as beans. We may want to revisit this, especially for the testing support. |
|
This turned out to bring a lot of subtle difference in the way bean definitions are registered. I've made a lot of progress with the help of @jhoeller but there are still a few cases that aren't working anymore. Investigating. |
snicoll
added a commit
to snicoll/spring-native
that referenced
this issue
Nov 17, 2021
Previously, BuildTimeBeanDefinitionsRegistrar was adding configuration class parsing manually and triggered it to build the list of bean definitions. Only certain framework callbacks were invoked. This commit harmonizes its processing so that it is as close as possible to what the regular runtime context would do. As a result, additional callbacks are invoked at build time which had a subtle impact on how bean definition types were discovered. To alleviate with that, BeanClassBeanDefinitionPostProcessor makes sure to resolve the bean class early if necessary. Closes spring-atticgh-1213
|
We're down to only the hibernate sample failing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
To get a full picture of the beans that are going to be contributed at runtime we should invoke
postProcessBeanDefinitionRegistryon the context at build time to feed theBeanFactorywith whateverBeanDefinitionRegistryPostProcessorbeans would contribute.This may fix the Spring Integration support as it currently contributes beans only at runtime and those beans require some additional reflection metadata.
The text was updated successfully, but these errors were encountered: