前言
现在几乎所有的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让人头大的源码，还是略过那些不重要的代码，直接来看重点和结论：
-
第一次进入SimpleApplicationEventMulticaster的这个方法，这个时候其实是应用启动事件，发现有4个监听器，但看上去没一个像跟配置有关的
-
第二次进这个方法，这个时候事件类型是环境准备事件，其中有个监听器是ConfigFileApplicationListener
-
进入ConfigFileApplicationListener的事件处理方法
- 通过ConfigFileApplicationListener的方法调用链onApplicationEnvironmentPreparedEvent --> postProcessEnvironment --> addPropertySources直接进入到内部类Loader的下面这个方法，其中常量NO_SEARCH_NAMES是包含单个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));
});
}
-
小心翼翼的一步一步往下走，本以为不会走进if条件，这样读到的就是application配置文件了，结果居然走了进去，而且"spring.config.name"对应的value是boostrap，而项目里根本没有配置boostrap.yaml文件，那这个值是哪来的呢？
- 找了个能正常启动的项目，同样的地方打上了断点，发现没进if条件，"spring.config.name"这个配置到底什么时候设置进去的，反复debug了好几遍，发现出错的应用多了一个监听器BootstrapApplicationListener，而这个监听器的优先级如下，比ConfigFileApplicationListener小多了(越小优先级越高)
public static final int DEFAULT_ORDER = Ordered.HIGHEST_PRECEDENCE + 5;
- 现在就剩一个问题了，为啥会多这么一个监听器呢？这个类所在的jar包是spring-cloud-context，分析了依赖发现正常启动的应用果然是没有这个依赖的。
结论
有时候默认的约定会给开发人员带来一定的困扰，就像springcloud默认会去读bootstrap的配置一样，而差别仅仅是依赖中是否含有对应的jar包。本篇的问题其实还有一种解决方案，就是直接将application.properties里的配置移动到bootstrap.properties里，这样apollo启用的配置就能从bootstrap.properties里读到了。
