关于springboot启动配置加载的那点事儿

前言

现在几乎所有的java开发都会用到springboot，除了很老很老的项目，应该不会再有人直接用jsp，servlet等写web项目了吧，直接用spring的都很少见了。今天发生的这个问题就得从springboot说起。我们都知道springboot遵循约定大于配置的规则，尽量将spring中的配置减少，几行代码就可以跑一个web项目，但是默认的东西越多，其实隐藏的东西也就越多，一旦碰到什么问题，如果没点准备，真的是会手忙脚乱的。

问题描述

说起来也不复杂，新拆分了一个项目，公司用的apollo作为配置中心，所以要做一些基本配置，让新项目从apollo拉取配置。本以为简单的Ctrl+C，Ctrl+V搞定，结果启动的时候报dubbo配置找不到，反复查看apollo，一个字母一个字母的比对过去，确定配置没有配错的，但是怎么就找不到呢？

源码分析

一般这种问题想从网上找到答案的可能性微乎其微，只好自己动手，深入源码，看看到底是哪个妖怪在作祟。

SpringApplicationRunListener和ApplicationContextInitializer

Dubbo配置的加载是架构组jar包提供的，定义了一个SpringApplicationRunListener的实现类，而apollo的配置加载是在ApplicationContextInitializer的一个实现类ApolloApplicationContextInitializer中处理的。所以一开始的怀疑Listener和Initializer在应用启动的时候的顺序问题。因为DubboListener里面加载dubbo的配置的代码在SpringApplicationRunListener的contextLoaded方法中，多以可以从下面SpringApplication的源码看到，Initializer的initialize方法是在Listener的contextLoaded方法之前执行的

private void prepareContext(ConfigurableApplicationContext context,
            ConfigurableEnvironment environment, SpringApplicationRunListeners listeners,
            ApplicationArguments applicationArguments, Banner printedBanner) {
    context.setEnvironment(environment);
    postProcessApplicationContext(context);
    // Initializer的initialize方法在这里执行
    applyInitializers(context);
    listeners.contextPrepared(context);
    if (this.logStartupInfo) {
        logStartupInfo(context.getParent() == null);
        logStartupProfileInfo(context);
    }

    // Add boot specific singleton beans
    context.getBeanFactory().registerSingleton("springApplicationArguments",
            applicationArguments);
    if (printedBanner != null) {
        context.getBeanFactory().registerSingleton("springBootBanner", printedBanner);
    }

    // Load the sources
    Set<Object> sources = getAllSources();
    Assert.notEmpty(sources, "Sources must not be empty");
    load(context, sources.toArray(new Object[0]));
    // Listener的contextLoaded方法在这里执行
    listeners.contextLoaded(context);
}

debug源码

猜测不对，只好跟着启动的源码debug观察了。这里省略一开始的猜测和尝试，直接进入重点：调试的时候有个发现，apollo的是否启用的配置值居然是false！可以从代码看到，方法直接返回了，并没有去加载apollo中的配置值，所以并不是顺序有问题，而是一开始是否启用的配置值有问题。

public void initialize(ConfigurableApplicationContext context) {
    ConfigurableEnvironment environment = context.getEnvironment();

    initializeSystemProperty(environment);
    // 如果这里配置是false，那方法直接return了
    String enabled = environment.getProperty(PropertySourcesConstants.APOLLO_BOOTSTRAP_ENABLED, "false");
    if (!Boolean.valueOf(enabled)) {
      logger.debug("Apollo bootstrap config is not enabled for context {}, see property: ${{}}", context, PropertySourcesConstants.APOLLO_BOOTSTRAP_ENABLED);
      return;
    }
    // 省略

查看项目中的application.properties文件，没啥问题啊(本来就是其他项目拷过来的，能有啥问题)，那怎么就读成false了呢？

apollo.bootstrap.enabled=true
apollo.bootstrap.namespaces=application,dev.common

只好继续debug让人头大的源码，还是略过那些不重要的代码，直接来看重点和结论：

1. 第一次进入SimpleApplicationEventMulticaster的这个方法，这个时候其实是应用启动事件，发现有4个监听器，但看上去没一个像跟配置有关的
   
2. 第二次进这个方法，这个时候事件类型是环境准备事件，其中有个监听器是ConfigFileApplicationListener
   
3. 进入ConfigFileApplicationListener的事件处理方法
   
4. 通过ConfigFileApplicationListener的方法调用链onApplicationEnvironmentPreparedEvent --> postProcessEnvironment --> addPropertySources直接进入到内部类Loader的下面这个方法，其中常量NOSEARCHNAMES是包含单个null元素的集合，这里获取到的names就是配置文件的名称。

private void load(Profile profile, DocumentFilterFactory filterFactory,
                DocumentConsumer consumer) {
    getSearchLocations().forEach((location) -> {
        boolean isFolder = location.endsWith("/");
        Set<String> names = (isFolder ? getSearchNames() : NO_SEARCH_NAMES);
        names.forEach(
                (name) -> load(location, name, profile, filterFactory, consumer));
    });
}

1. 小心翼翼的一步一步往下走，本以为不会走进if条件，这样读到的就是application配置文件了，结果居然走了进去，而且"spring.config.name"对应的value是boostrap，而项目里根本没有配置boostrap.yaml文件，那这个值是哪来的呢？
   
2. 找了个能正常启动的项目，同样的地方打上了断点，发现没进if条件，"spring.config.name"这个配置到底什么时候设置进去的，反复debug了好几遍，发现出错的应用多了一个监听器BootstrapApplicationListener，而这个监听器的优先级如下，比ConfigFileApplicationListener小多了(越小优先级越高)

public static final int DEFAULT_ORDER = Ordered.HIGHEST_PRECEDENCE + 5;

1. 现在就剩一个问题了，为啥会多这么一个监听器呢？这个类所在的jar包是spring-cloud-context，分析了依赖发现正常启动的应用果然是没有这个依赖的。

结论

有时候默认的约定会给开发人员带来一定的困扰，就像springcloud默认会去读bootstrap的配置一样，而差别仅仅是依赖中是否含有对应的jar包。本篇的问题其实还有一种解决方案，就是直接将application.properties里的配置移动到bootstrap.properties里，这样apollo启用的配置就能从bootstrap.properties里读到了。

本文由博客一文多发平台 OpenWrite 发布！