SpringBoot When a BeanDefinitionRegistryPostProcessor bean is depends on a properties bean, the properties bean will not load the properties from application.yml

application.ym :

the SeataAutoDataSourceProxyCreator :

instantiate SeataAutoDataSourceProxyCreator:

Is this a bug? I think the environment has been loaded. It can provide the properties.

springboot: 2.5.14 or 2.7.6 is tested. When I remove the BeanDefinitionRegistryPostProcessor from the implements, it will load properties normally.

Comment From: kse-music

SeataAutoDataSourceProxyCreator implements BeanDefinitionRegistryPostProcessor lead to premature instantiation, various BeanPostProcessor not instantiate yet, such as processing bean Configuration binding's ConfigurationPropertiesBindingPostProcessor, so the SeataProperties will not be processed.

Comment From: wangliang181230

SeataAutoDataSourceProxyCreator implements BeanDefinitionRegistryPostProcessor lead to premature instantiation, various BeanPostProcessor not instantiate yet, such as processing bean Configuration binding's ConfigurationPropertiesBindingPostProcessor, so the SeataProperties will not be processed.

If I need some properties, can I only load them from the environment?

Comment From: kse-music

SeataAutoDataSourceProxyCreator implements BeanDefinitionRegistryPostProcessor lead to premature instantiation, various BeanPostProcessor not instantiate yet, such as processing bean Configuration binding's ConfigurationPropertiesBindingPostProcessor, so the SeataProperties will not be processed.

If I need some properties, can I only load them from the environment?

maybe you can write like this

public SeataAutoDataSourceProxyCreator seataAutoDataSourceProxyCreator(Environment environment, SeataProperties seataProperties){
    Binder.get(environment).bind("seata", Bindable.ofInstance(seataProperties));

    return new SeataAutoDataSourceProxyCreator (...);
}

Comment From: bclozel

@wangliang181230 I think @kse-music is right, BeanDefinitionRegistryPostProcessor is applied on bean definitions, way before any instantiation occurs. You cannot rely on properties beans being resolved and created at this phase of the application context. You can always bind directly from the environment, but note that chances are that EnvironmentPostProcessor were not applied at this stage so you might get the wrong property value. I'd suggest revisiting this contract with the context lifecycle in mind.

Comment From: wangliang181230

@bclozel @kse-music Thank you for your answer. I have got it.

Comment From: wangliang181230

but note that chances are that EnvironmentPostProcessor were not applied at this stage so you might get the wrong property value.

@bclozel I tested, the EnvironmentPostProcessor is loaded first.