解决SpringBoot加载application.properties配置文件的坑解决SpringBoot加载application.pro

SpringBoot加载application.properties配置文件的坑事情的起因是这样的
一次，本人在现场升级程序，升级完成后进行测试，结果接口调用都报了这么个错误：

文章图片

大概意思是https接口需要证书校验，这就奇怪了，项目启动加载的是包外的application.properties配置文件，配置文件里没有配置使用https啊。本人马上检查了下包内的application.properties配置文件，发现包内确实配置了https相关的配置项：

文章图片

明明包外的配置文件优先级高于包内的，为啥包内的一部分配置项起作用了呢，我们了解的配置文件优先级是这样的：

文章图片

这是为啥呢？后来才了解到除了高优先级覆盖低优先级外，还有一条重要的规则：如有不同内容，高优先级和低优先级形成互补配置。这下才恍然大悟，我包外的配置文件里把https相关的配置项注释掉了，相当于没有这个配置项，但是包内的配置文件有，根据互补原则，包内的这几个配置项起作用了。
问题原因找到了，如何解决呢？
要不我把包内的那几个配置项也注释掉，重新打个包？其实不必这么麻烦，通过-Dspring.config.location命令直接指定包外的配置文件就可以了，试了下，果然没有问题了。问题虽然解决了，但是还有些疑问，为啥指定包外的配置文件后就不存在互补情况了呢？
通过阅读springboot相关源码，找到了答案：

文章图片

大概意思是：
如果-Dspring.config.location指定了配置文件，则只加载指定的那一个配置文件，如果没有专门指定配置文件则遍历包外、包内相关的配置文件，按照高优先级覆盖低优先级和互补原则进行加载。
弄明白这些问题后，实地部署项目的时候，保险起见还是通过-Dspring.config.location命令直接指定加载的配置文件比较好，避免出现一些不必要的麻烦。
Spring Boot加载application.properties探究基于Spring Boot的多Module项目中，有许多公共的配置项，为避免在每个接入层都配置一遍，一个设想是在公共依赖的Module的application.properties(application.yml)中进行配置。原来的配置文件位于接入层的classpath，可由Spring Boot打包插件打入，一旦置于公共Module，配置文件就不再直接被打入jar包，而是位于内嵌的jar包中，并不确认Spring Boot会去扫内嵌于jar包中的application文件，因此可行性有待验证。
探索
实验准备，项目结构如下所示：

Demo - web(接入层)- src- main- java- resources- application.properties // 1 - test- pom.xml - common(公共层)- src- main- java- resources- application-dev.properties // 2 - pom.xml(父Module pom)

接入层为web，在resources下存在application.properties，内容为spring.profiles.active=dev，目的是为了激活dev的profile
公共同为common，在在resources下存在application-dev.properties，内容为name=demo_test
因此，如果配置项name=demo_test能够被应用成功读取到，那么就验证了在背景中提及的设想
实验结果：成功读取
原理分析
一般地，Spring Boot 默认的配置文件名称为：application.properties或application.yml，为方便描述，统一为application.properties。从Spring Boot 官方文档得知，Spring Boot可以从下述位置按顺序加载配置文件

A /config subdirectory of the current directory(file:./config/)The current directory(file:./)A classpath /config package(classpath:/config/)The classpath root(classpath:/)

优先级表述如下：

The list is ordered by precedence (properties defined in locations higher in the list override those defined in lower locations).

也即是说，排在前边的优先级高于排在后边的。这里有几层隐含的含义，在官方文档中并没有表述清楚，为方便记忆与理解
总结如下： 1、上边的4个位置均可放置配置文件(application.properties)
它们之间是一个并集关系而不是互斥关系，Spring Boot 默认都会加载到它们，而不是加载到高优先级的配置文件之后就停止加载低优先级的
2、如果在两个以上的application.properties里配置
同一个配置项(如: name=demo)，那么优先级高的配置项会生效
举个例子，项目结构如下

src - main- resources- config- application.properties // 3 (k1=v1, k2=v2)- application.properties // 4(k1=v3, k4=v4)

在优先级排名第3的配置文件中，存在两个配置项(k1=v1, k2=v2)；在优先级排名第4的配置文件中，存在两个配置项(k1=v3, k4=v4)。内存中，四个配置项都存在，但生效的配置项只有三个：k1=v1,k2=v2,k4=v4，而k1=v3由于优先级比较低，并不生效
在Spring Boot应用启动过程中，需要创建ConfigurableEnvironment，当Environment创建完，Spring 会发布ApplicationEnvironmentPreparedEvent事件，告知Environment创建完毕。ConfigFileApplicationListener会监听这个事件，在事件处理中，使用Spring SPI机制加载EnvironmentPostProcessor集合，并回调EnvironmentPostProcessor#postProcessEnvironment方法。很巧的是，ConfigFileApplicationListener同时也实现了EnvironmentPostProcessor，因此，会回调到自身的postProcessEnvironment方法中。
注：下边的源码基于Spring Boot 2.1.10.RELEASE

// org.springframework.boot.SpringApplication#run(java.lang.String...)public ConfigurableApplicationContext run(String... args) { // ...(省略) listeners.starting(); try {ApplicationArguments applicationArguments = new DefaultApplicationArguments(args); // 创建ConfigurableEnvironmentConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments); // ...(省略)}

// org.springframework.boot.SpringApplication#run(java.lang.String...)private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners,ApplicationArguments applicationArguments) { // Create and configure the environment ConfigurableEnvironment environment = getOrCreateEnvironment(); configureEnvironment(environment, applicationArguments.getSourceArgs()); ConfigurationPropertySources.attach(environment); // 发布ApplicationEnvironmentPreparedEvent事件 listeners.environmentPrepared(environment); // ...(省略)}// org.springframework.boot.SpringApplicationRunListeners#environmentPreparedpublic void environmentPrepared(ConfigurableEnvironment environment) { for (SpringApplicationRunListener listener : this.listeners) {listener.environmentPrepared(environment); }}// org.springframework.boot.context.event.EventPublishingRunListener#environmentPreparedpublic void environmentPrepared(ConfigurableEnvironment environment) {// 发布ApplicationEnvironmentPreparedEvent事件 this.initialMulticaster.multicastEvent(new ApplicationEnvironmentPreparedEvent(this.application, this.args, environment)); }

// org.springframework.boot.context.config.ConfigFileApplicationListenerprivate void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) { // 利用Spring SPI机制加载EnvironmentPostProcessor List postProcessors = loadPostProcessors(); postProcessors.add(this); AnnotationAwareOrderComparator.sort(postProcessors); for (EnvironmentPostProcessor postProcessor : postProcessors) {// 回调postProcessor.postProcessEnvironment(event.getEnvironment(), event.getSpringApplication()); }}

在postProcessEnvironment回调中，添加了RandomValuePropertySource，并调用内部类Loader的load方法，对application.properties进行加载

// org.springframework.boot.context.config.ConfigFileApplicationListenerpublic void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) { addPropertySources(environment, application.getResourceLoader()); }protected void addPropertySources(ConfigurableEnvironment environment, ResourceLoader resourceLoader) {// 添加`RandomValuePropertySource`到Environment RandomValuePropertySource.addToEnvironment(environment); // load()方法是重点; new Loader(environment, resourceLoader).load(); }

// org.springframework.boot.context.config.ConfigFileApplicationListener.Loader#load()public void load() { this.profiles = new LinkedList<>(); this.processedProfiles = new LinkedList<>(); this.activatedProfiles = false; this.loaded = new LinkedHashMap<>(); // 以上四个变量默认状态为空集合或false，用于在下边迭代的过程中收集数据 // 初始化profiles集合，如果存在active的profile，会将activatedProfiles变量设置为true initializeProfiles(); while (!this.profiles.isEmpty()) {Profile profile = this.profiles.poll(); if (profile != null && !profile.isDefaultProfile()) {addProfileToEnvironment(profile.getName()); }load(profile, this::getPositiveProfileFilter, addToLoaded(MutablePropertySources::addLast, false)); this.processedProfiles.add(profile); } resetEnvironmentProfiles(this.processedProfiles); load(null, this::getNegativeProfileFilter, addToLoaded(MutablePropertySources::addFirst, true)); addLoadedPropertySources(); }

初始化profiles集合，如果存在active的profile，会将activatedProfiles变量设置为true。这里需要注意的是，在案例demo中，是将spring.profiles.active=dev写在classpath的application.properties，而此时application.properties都还没有读取，所以该配置项并未生效。故此，active的profile指的是那些通过system property、system enviroment、手动调用AbstractEnvironment#setActiveProfiles等方式设置active profile，他们的共同特点是优先级都较高，配置项初始化早，在执行load方法前就已生效
先往profiles集合添加null，表示将要加载那些跟profile无关的application.properties，并且如果没有active profile，那还会加载名为default的profile

private void initializeProfiles() { // The default profile for these purposes is represented as null. We add it // first so that it is processed first and has lowest priority. this.profiles.add(null); Set activatedViaProperty = getProfilesActivatedViaProperty(); this.profiles.addAll(getOtherActiveProfiles(activatedViaProperty)); // Any pre-existing active profiles set via property sources (e.g. // System properties) take precedence over those added in config files. addActiveProfiles(activatedViaProperty); if (this.profiles.size() == 1) { // only has null profilefor (String defaultProfileName : this.environment.getDefaultProfiles()) {// 加载名为`default`的profileProfile defaultProfile = new Profile(defaultProfileName, true); this.profiles.add(defaultProfile); } }}

initializeProfiles方法执行完毕之后，只要profiles非空，就从队首取出并进行加载。profiles是个双端队列，加载的过程有可能往队列里添加或者移除元素，因此使用的是while (!this.profiles.isEmpty())的判断方式。
接着看load(profile, this::getPositiveProfileFilter, addToLoaded(MutablePropertySources::addLast, false));
该方法结构很清晰，迭代每一个location(搜索路径)，如果搜索路径是个目录(以/结尾)，则获取配置文件名，然后结合搜索路径+配件文件名对配置文件进行加载。这儿隐含一层意思：location可以直接指定为配置文件，但是此种方式不被推荐使用，因为这会导致Profile机制失效，建议还是按正常的姿势去使用

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

获取搜索路径，
可由spring.config.location指定或者spring.config.additional-location + classpath:/,classpath:/config/,file:./,file:./config/。注意此处，spring.config.location指定的搜索顺序跟定义的顺序相反，例如指定的位置为a, b, c，则按c, b, a的顺序进行搜索，而搜索顺序反应的是配置项的优先级，在上边已提过，不再赘述

private Set getSearchLocations() { // 若通过 spring.config.location 指定配置文件目录，则到指定路径查找，不再走默认的搜索路径和额外添加的路径，可以指定多个，以逗号进行分隔 // CONFIG_LOCATION_PROPERTY = spring.config.location if (this.environment.containsProperty(CONFIG_LOCATION_PROPERTY)) {return getSearchLocations(CONFIG_LOCATION_PROPERTY); } // 除了默认路径，还可以通过 spring.config.additional-location 指定额外的搜索路径 // CONFIG_ADDITIONAL_LOCATION_PROPERTY = spring.config.additional-location Set locations = getSearchLocations(CONFIG_ADDITIONAL_LOCATION_PROPERTY); // 默认搜索路径 // DEFAULT_SEARCH_LOCATIONS = classpath:/,classpath:/config/,file:./,file:./config/ locations.addAll(asResolvedSet(ConfigFileApplicationListener.this.searchLocations, DEFAULT_SEARCH_LOCATIONS)); return locations; }

该方法将搜索路径或者指定的配置文件名以逗号分割后倒置

private Set asResolvedSet(String value, String fallback) { List list = Arrays.asList(StringUtils.trimArrayElements(StringUtils.commaDelimitedListToStringArray((value != null) ? this.environment.resolvePlaceholders(value) : fallback))); Collections.reverse(list); return new LinkedHashSet<>(list); }

获取待搜索的配置文件名，可由spring.config.name指定或者使用默认值application，同上面的搜索路径一样，spring.config.name指定的搜索顺序跟定义的顺序相反

private Set getSearchNames() { // 若通过 spring.config.name 指定配置文件名称，则只会搜索该名称的配置文件，可以指定多个，以逗号进行分隔 // CONFIG_NAME_PROPERTY = spring.config.name if (this.environment.containsProperty(CONFIG_NAME_PROPERTY)) {String property = this.environment.getProperty(CONFIG_NAME_PROPERTY); return asResolvedSet(property, null); } // 默认搜索的配置文件名称为application // DEFAULT_NAMES = application return asResolvedSet(ConfigFileApplicationListener.this.names, DEFAULT_NAMES); }

在我们的案例中，没有通过spring.config.location指定配置文件目录，也没有通过spring.config.name指定配置文件名，因此都采用默认值，且顺序倒置：

localtion:file:./config/, file:./, classpath:/config/, classpath:/
config.name: application

且只在classpath:/放有配置文件application.properties与application-dev.properties
接着，遍历propertySourceLoaders对配置文件进行加载。propertySourceLoaders是在构造Loader类时进行初始化的，它利用Spring SPI机制对实现类进行加载，默认实现类有两个

PropertiesPropertySourceLoader: 加载.properties与.xml的配置文件
YamlPropertySourceLoader: 加载.yml和.yaml的配置文件

private void load(String location, String name, Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) { // ...(省略) Set processed = new HashSet<>(); for (PropertySourceLoader loader : this.propertySourceLoaders) {for (String fileExtension : loader.getFileExtensions()) {// .properties\.xml\.yml\.yamlif (processed.add(fileExtension)) {loadForFileExtension(loader, location + name, "." + fileExtension, profile, filterFactory,consumer); }} }}

private void loadForFileExtension(PropertySourceLoader loader, String prefix, String fileExtension, Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) { DocumentFilter defaultFilter = filterFactory.getDocumentFilter(null); DocumentFilter profileFilter = filterFactory.getDocumentFilter(profile); if (profile != null) {// Try profile-specific file & profile section in profile file (gh-340)// profileSpecificFile = file:./application-dev.propertiesString profileSpecificFile = prefix + "-" + profile + fileExtension; // 加载profile对应的配置文件load(loader, profileSpecificFile, profile, defaultFilter, consumer); load(loader, profileSpecificFile, profile, profileFilter, consumer); // Try profile specific sections in files we've already processedfor (Profile processedProfile : this.processedProfiles) {if (processedProfile != null) {String previouslyLoaded = prefix + "-" + processedProfile + fileExtension; load(loader, previouslyLoaded, profile, profileFilter, consumer); }} } // Also try the profile-specific section (if any) of the normal file // 加载非profile的配置文件 load(loader, prefix + fileExtension, profile, profileFilter, consumer); }

使用resourceLoader到location获取配置文件资源，resourceLoader也是在Loader类构造的时候初始化的，默认是DefaultResourceLoader，它是Spring提供的ResourceLoader的默认实现类，能够获取classpath资源以及URL资源或类URL资源，资源用Resource进行抽象表示。
此处，已经可以解释文章探索实验的结果：资源的获取是靠Spring提供的DefaultResourceLoader实现的，它能够实现classpath的扫描，进而加载资源，因此，只要是classpath下的配置文件，无论是否在内嵌jar包内，最终都能加载到
有了Loader，以及Resource，就可以进行资源的加载，加载的结果是List，代表对配置文件属性源的抽象以及封装。用DocumentFilter对满足条件的Document进行过滤，满足条件的则被添加进MutablePropertySources中

private void load(PropertySourceLoader loader, String location, Profile profile, DocumentFilter filter, DocumentConsumer consumer) { try {Resource resource = this.resourceLoader.getResource(location); // ...(省略)String name = "applicationConfig: [" + location + "]"; List documents = loadDocuments(loader, name, resource); // ...(省略)List loaded = new ArrayList<>(); for (Document document : documents) {if (filter.match(document)) {addActiveProfiles(document.getActiveProfiles()); addIncludedProfiles(document.getIncludeProfiles()); loaded.add(document); }}Collections.reverse(loaded); if (!loaded.isEmpty()) {loaded.forEach((document) -> consumer.accept(profile, document)); // ...(省略)}

最终，被加载的配置文件存在loaded变量中，调用addLoadedPropertySources方法，将loaded倒置之后添加进environment的PropertySources中，倒置的目的，是为了使profile的配置文件优先级更高。而一旦将配置项添加进environment的属性源集合中，应用程序就能正确取读到配置项。

// org.springframework.boot.context.config.ConfigFileApplicationListener.Loader#addLoadedPropertySourcesprivate void addLoadedPropertySources() { MutablePropertySources destination = this.environment.getPropertySources(); List loaded = new ArrayList<>(this.loaded.values()); Collections.reverse(loaded); String lastAdded = null; Set added = new HashSet<>(); for (MutablePropertySources sources : loaded) {for (PropertySource source : sources) {if (added.add(source.getName())) {addLoadedPropertySource(destination, lastAdded, source); lastAdded = source.getName(); }} }}

其实，application-{profile}.properties配置文件加载位置同标准的application.properties，但是它有一点显著不同的是，无论application-{profile}.properties放哪，profile类的配置文件优先级最高，当配置项冲突时，总是"覆盖"一切非profile的配置文件
总结
本文开篇提出一个问题：在依赖的公共Module的classpath放置application.properties，Spring Boot应用能否正确读取？之后通过案例进行实验，证明了此行为的可行性。为了了解Spring Boot对application.properties加载的过程，先是阅读了Spring Boot 官方文档对application.properties的介绍，并对其中关于配置项优先级的模糊描述做了进一步的解释。接着从源码的角度，对application.properties的加载过程从头到尾简单介绍了一遍，了解到ResourceLoader及其默认实现类DefaultResourceLoader正是用于从classpath加载资源，因此能成功加载内嵌jar包中位于classpath的application.properties
最后，介绍了Spring Boot对于PropertySource优先级处理的原则：后赢策略(last-wins)，加载的过程按代码定义的顺序先加载，放入数据源之前进行倒置(reverse)放入，在后边的反而优先级高
题外话
1、配置文件前2优先级位置分别是：file:./config/、file:./，在IDEA中是指当前项目的/config目录以及当前项目根目录。如果是多module项目，那么当前项目指的是父module目录。其实在IDEA环境中使用这俩位置的配置文件意义不大，更多的，是与发布系统结合，发布系统将服务打成Executable Jar之后，将应用相关的基础配置信息（如server.port、Apollo apollo.meta\env ）配置在./config/或者./，用以覆盖项目内有可能误配或漏配的选项
2、本文的一些规律，不单适用于application.properties，还适用于别的配置文件。例如：配置项优先级原则，基本思想是：由Spring加载所有的属性源到Environment中，通过属性源的方式将配置项进行隔离，不同的属性源互不干扰，在此基础上，靠前的属性源的配置项优先级高。这种行为是Spring默认的行为，该行为定义在PropertySourcesPropertyResolver，也意味着，我们可以自定义PropertyResolver，来改变这种默认的行为，实现自定义的优先级顺序，达到我们的目的
3、关于application.properties的加载过程，还有很多细节未曾提及，这并非意味着不重要，而是一篇文章难以面面俱到，而陷入源码细节容易一叶障目。从问题出发，梳理主干脉络，把握核心思想，是为首要条件，之后每次根据需要，像剥洋葱般一层层深入，能更容易掌握知识
【解决SpringBoot加载application.properties配置文件的坑】以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。