vsersion spring boot v2.3.12

description Because of the order of the AnnotationConfigWebApplicationContext.loadBeanDefinitions @Configuration create bean before spring.factories org.springframework.boot.autoconfigure.EnableAutoConfiguration

In some scenarios, will cause @AutoConfigureBefore unvaild, such as

@SpringApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @Resource
    public KafkaTemplate kafkaTemplate;

}

// custom starter
@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties({KafkaProperties.class})
@AutoConfigureBefore({KafkaAutoConfiguration.class})
public class KafkaPropertiesCustomizerAutoConfiguration {

    private final KafkaProperties kafkaProperties;

    public KafkaPropertiesCustomizerAutoConfiguration(
            KafkaProperties kafkaProperties) {
        this.kafkaProperties = kafkaProperties;
    }

    @PostConstruct
    public void customKafkaProperties() {
        CCDefaultKafkaProperties.customKafkaProperties(kafkaProperties);
    }

}

# spring.factories
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.caocao.middleware.springboot.autoconfigure.kafka.KafkaPropertiesCustomizerAutoConfiguration

in this case KafkaAutoConfiguration will init first, cause @AutoConfigureBefore vaild

Comment From: wilkinsona

For @Configuration to have any effect on ordering, the package that contains KafkaPropertiesCustomizerAutoConfiguration must be covered by component scanning. This must be avoided:

Auto-configurations must be loaded only by being named in the imports file. Make sure that they are defined in a specific package space and that they are never the target of component scanning. Furthermore, auto-configuration classes should not enable component scanning to find additional components. Specific @Import annotations should be used instead.

If this does not help and you would like us to re-open the issue and spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Comment From: Wzy19930507

Hi, @wilkinsona https://github.com/Wzy19930507/spring-boot-issue/tree/master

Version Spring boot 3.1.5

I expect the output FirstAutoConfiguration SecondAutoConfiguration demo

Actual output SecondAutoConfiguration demo FirstAutoConfiguration

Actual output meets the expectations of spring boot?

Comment From: wilkinsona

Actual output meets the expectations of spring boot?

Yes.

Auto-configuration ordering controls the order in which beans are defined. It does not control the order in which they are created. If you want to control the order in which otherwise unrelated beans are created, you can use @DependsOn.

Comment From: Wzy19930507

Thank you very much.

Comment From: Wzy19930507

Hi, @wilkinsona https://github.com/Wzy19930507/spring-boot-issue/tree/issue_20231024

Version Spring boot 3.1.5

describe In my sense need start KafkaPropertiesCustomizerAutoConfiguration before KafkaAutoConfiguration do some preparatory work. KafkaAutoConfiguration is open source, i can't use @DependsOn control the order. @Order is invaild in this case.

Sorry to bother you again, is there any solution to the above problem

Comment From: wilkinsona

It looks like you're trying to change KafkaProperties before anything uses them. Before going any further, please note that this isn't supported as we do not consider the getters and setters of configuration properties classes to be public API and breaking change may be made at any time. If you're comfortable with that risk, specific ordering between two beans isn't going to help as there may be other beans consuming the properties for which the ordering will be wrong.

If you want to change the properties before anyone uses them, either an EnvironmentPostProcessor that sets properties before they are bound or a BeanPostProcessor would be a better option. The latter would have to run after ConfigurationPropertiesBindingPostProcessor which should happen by default as ConfigurationPropertiesBindingPostProcessor is priority ordered with almost highest precedence.

If you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

Comment From: Wzy19930507

I got it, thank you for your time and professional response