记一次使用spring javaconfig踩到的坑

前言

为了简化开发，我部门经常会封装一些通用的类库给业务研发使用，因为业务方的根包路径很经常和我们部门项目的根包是不一样的，因此我们会让业务方在使用我们封装的包时，扫描一下我们的根包，形如下

@ComponentScan(basePackages = {"com.aaa","com.bbb"})
复制代码

不过这样就导致了业务方想使用我们的类库，就必须知道我们的根包。这其实是一种间接的耦合。后面我们就全面使用springboot的自动装配，让业务方无需知道我们的根包，也可以使用我们的类库。然而在我们封装的过程中，也遇到一些坑。本文就来复盘一次我们使用spring javaconfig踩到的坑。本文主要是demo示例演示

demo示例

假设我们封装了一个类库DemoService。示例如下

public class DemoService {

    private DemoProperties demoProperties;

    private String version;


    public DemoService(DemoProperties demoProperties) {
        this.demoProperties = demoProperties;
    }

    public String print(){
        return "version:" + version + ">>>>>>>>>>" + demoProperties;
    }

    public String getVersion() {
        return version;
    }

    public void setVersion(String version) {
        this.version = version;
    }
}

复制代码

DemoProperties 类如下

@ConfigurationProperties(prefix = "demo.hello")
public class DemoProperties {

    private String name;


    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "DemoProperties{" +
                "name='" + name + '\'' +
                '}';
    }
}
复制代码

有个针对DemoService的扩展后置处理器

public class DemoBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

    @Override
    public void postProcessBeanFact