BeanFactoryPostProcessor and @Bean problems

[vongosling]

some lib using BFPP to do customized things,i want to modify this to spring boot,so I use this styple

@Bean
@ConditionalOnMissingBean
public BeanFactoryPostProcessor hSpringProviderPackageScanner() {
  .....
  Environment env = applicationContext.getEnvironment();
}

But this method would result in my datasource properties can not autowired,as @bean javadoc said.i try to modify hSpringProviderPackageScanner to static,but in my hSpringProviderPackageScanner method ,I want to get some beans from applicationContext(but can not get this instance from static field) . how to do this ?please give me some advice

[wilkinsona]

Sorry, but I'm not sure that I understand what it is that you're trying to do. A few comments that will hopefully help:

• The use of @ConditionalOnMissing doesn't look right to me. As described in the documentation we only recommend using it on an auto-configuration class.
• Why do you need to get some beans from the application context in your hsfSpringProviderPackageScanner method? BeanFactoryPostProcessors are created very early so you need to be careful about accessing any beans there.

Can you please provide a small example of what you're trying to do that illustrates the problem you're seeing?

Lastly, in the future can you please ask this sort of question on Stack Overflow? As described in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

[vongosling]

sorry.I make supplement that our @ConditionalOnMissing is using on auto-configuration.for integrity,I paste full code，Stack Overflow?that's good place for some problems,but i have not found the similar problem

@Configuration
@ConditionalOnBean(annotation = EnableHProvider.class)
public class HAnnotationConfiguration implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }

    @Bean
    @ConditionalOnMissingBean
    public BeanFactoryPostProcessor hSpringProviderPackageScanner() {
        HSpringProviderPackageScanner scanner = new HSpringProviderPackageScanner();
        Environment env = applicationContext.getEnvironment();
        String[] beanNames = applicationContext.getBeanNamesForAnnotation(EnableHProvider.class);
        if (beanNames != null && beanNames.length > 0) {
            Object entrance = applicationContext.getBean(beanNames[0]);
            EnableHProvider enableHProvider = entrance.getClass().getAnnotation(EnableHProvider.class);
            scanner.setPackageName(enableHProvider.scan());
            scanner.setServiceGroup(enableHProvider.group().getName());

[vongosling]

My question is how to avoid lifecycle problems if i could not modify class HSpringProviderPackageScanner(let it not implement BeanFactoryPostProcessor).if i modify hSpringProviderPackageScanner signature to static(thus can void this problems as @bean javadoc said) ,i could not get some properties from application.properties file as my code description(because here applicationContext can not be injected).so,is there any other solutions?

[wilkinsona]

Stack Overflow?that's good place for some problems,but i have not found the similar problem

I wasn't suggesting that you'll find an existing answer to this problem on Stack Overflow. I was asking you to post this sort of question to Stack Overflow in the future so that the Stack Overflow community can, hopefully, provide an answer. It's a better place for Q&A as this issue tracker is intended for tracking bugs and enhancements.

My question is how to avoid lifecycle problems

Rather than using the ApplicationContext to retrieve the bean names, you can use the ConfigurableListableBeanFactory that's passed into the BeanFactoryPostProcessor. I believe it's also possible for a BeanFactoryPostProcessor to be EnvironmentAware which will give you access to the Environment.

All of that said, you're still calling getBean during BeanFactoryPostProcessor creation. Generally speaking, that's not a good idea as it'll cause that bean and all of its dependencies to be created very early in the lifecycle of the application context. If you know that any beans annotated with EnableHProvider will have minimal dependencies then you might be able to get away with it. It's impossible for me to say for certain without seeing all of the code involved.

If the above doesn't answer your question, please provide a complete example that illustrates the problem.

[vongosling]

yeah.thank you very much.your answer like environmentaware may be a good idea.i will try it.beanfactory also sounds a good idear.but i must hack lib code.so i will try my best as your advice😀