解決SpringBoot加載application.properties配置文件的坑
SpringBoot加載application.properties配置文件的坑
事情的起因是這樣的
一次,本人在現(xiàn)場升級程序,升級完成后進行測試,結果接口調用都報了這么個錯誤:

大概意思是https接口需要證書校驗,這就奇怪了,項目啟動加載的是包外的application.properties配置文件,配置文件里沒有配置使用https啊。本人馬上檢查了下包內的application.properties配置文件,發(fā)現(xiàn)包內確實配置了https相關的配置項:

明明包外的配置文件優(yōu)先級高于包內的,為啥包內的一部分配置項起作用了呢,我們了解的配置文件優(yōu)先級是這樣的:

這是為啥呢?后來才了解到除了高優(yōu)先級覆蓋低優(yōu)先級外,還有一條重要的規(guī)則:如有不同內容,高優(yōu)先級和低優(yōu)先級形成互補配置。這下才恍然大悟,我包外的配置文件里把https相關的配置項注釋掉了,相當于沒有這個配置項,但是包內的配置文件有,根據(jù)互補原則,包內的這幾個配置項起作用了。
問題原因找到了,如何解決呢?
要不我把包內的那幾個配置項也注釋掉,重新打個包?其實不必這么麻煩,通過-Dspring.config.location命令直接指定包外的配置文件就可以了,試了下,果然沒有問題了。問題雖然解決了,但是還有些疑問,為啥指定包外的配置文件后就不存在互補情況了呢?
通過閱讀springboot相關源碼,找到了答案:

大概意思是:
如果-Dspring.config.location指定了配置文件,則只加載指定的那一個配置文件,如果沒有專門指定配置文件則遍歷包外、包內相關的配置文件,按照高優(yōu)先級覆蓋低優(yōu)先級和互補原則進行加載。
弄明白這些問題后,實地部署項目的時候,保險起見還是通過-Dspring.config.location命令直接指定加載的配置文件比較好,避免出現(xiàn)一些不必要的麻煩。
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,為方便描述,統(tǒng)一為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:/)
優(yōu)先級表述如下:
The list is ordered by precedence (properties defined in locations higher in the list override those defined in lower locations).
也即是說,排在前邊的優(yōu)先級高于排在后邊的。這里有幾層隱含的含義,在官方文檔中并沒有表述清楚,為方便記憶與理解
總結如下:
1、上邊的4個位置均可放置配置文件(application.properties)
它們之間是一個并集關系而不是互斥關系,Spring Boot 默認都會加載到它們,而不是加載到高優(yōu)先級的配置文件之后就停止加載低優(yōu)先級的
2、如果在兩個以上的application.properties里配置
同一個配置項(如: name=demo),那么優(yōu)先級高的配置項會生效
舉個例子,項目結構如下
src
- main
- resources
- config
- application.properties // 3 (k1=v1, k2=v2)
- application.properties // 4 (k1=v3, k4=v4)
在優(yōu)先級排名第3的配置文件中,存在兩個配置項(k1=v1, k2=v2);在優(yōu)先級排名第4的配置文件中,存在兩個配置項(k1=v3, k4=v4)。內存中,四個配置項都存在,但生效的配置項只有三個:k1=v1,k2=v2,k4=v4,而k1=v3由于優(yōu)先級比較低,并不生效
在Spring Boot應用啟動過程中,需要創(chuàng)建ConfigurableEnvironment,當Environment創(chuàng)建完,Spring 會發(fā)布ApplicationEnvironmentPreparedEvent事件,告知Environment創(chuàng)建完畢。ConfigFileApplicationListener會監(jiān)聽這個事件,在事件處理中,使用Spring SPI機制加載EnvironmentPostProcessor集合,并回調EnvironmentPostProcessor#postProcessEnvironment方法。很巧的是,ConfigFileApplicationListener同時也實現(xiàn)了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);
// 創(chuàng)建ConfigurableEnvironment
ConfigurableEnvironment 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);
// 發(fā)布ApplicationEnvironmentPreparedEvent事件
listeners.environmentPrepared(environment);
// ...(省略)
}
// org.springframework.boot.SpringApplicationRunListeners#environmentPrepared
public void environmentPrepared(ConfigurableEnvironment environment) {
for (SpringApplicationRunListener listener : this.listeners) {
listener.environmentPrepared(environment);
}
}
// org.springframework.boot.context.event.EventPublishingRunListener#environmentPrepared
public void environmentPrepared(ConfigurableEnvironment environment) {
// 發(fā)布ApplicationEnvironmentPreparedEvent事件
this.initialMulticaster
.multicastEvent(new ApplicationEnvironmentPreparedEvent(this.application, this.args, environment));
}
// org.springframework.boot.context.config.ConfigFileApplicationListener
private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
// 利用Spring SPI機制加載EnvironmentPostProcessor
List<EnvironmentPostProcessor> 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.ConfigFileApplicationListener
public 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<>();
// 以上四個變量默認狀態(tài)為空集合或false,用于在下邊迭代的過程中收集數(shù)據(jù)
// 初始化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,他們的共同特點是優(yōu)先級都較高,配置項初始化早,在執(zhí)行l(wèi)oad方法前就已生效
先往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<Profile> 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 profile
for (String defaultProfileName : this.environment.getDefaultProfiles()) {
// 加載名為`default`的profile
Profile defaultProfile = new Profile(defaultProfileName, true);
this.profiles.add(defaultProfile);
}
}
}
initializeProfiles方法執(zhí)行完畢之后,只要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<String> 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的順序進行搜索,而搜索順序反應的是配置項的優(yōu)先級,在上邊已提過,不再贅述
private Set<String> 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<String> 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<String> asResolvedSet(String value, String fallback) {
List<String> 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<String> 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機制對實現(xiàn)類進行加載,默認實現(xiàn)類有兩個
PropertiesPropertySourceLoader: 加載.properties與.xml的配置文件
YamlPropertySourceLoader: 加載.yml和.yaml的配置文件
private void load(String location, String name, Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) {
// ...(省略)
Set<String> processed = new HashSet<>();
for (PropertySourceLoader loader : this.propertySourceLoaders) {
for (String fileExtension : loader.getFileExtensions()) {
// .properties\.xml\.yml\.yaml
if (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.properties
String 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 processed
for (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的默認實現(xiàn)類,能夠獲取classpath資源以及URL資源或類URL資源,資源用Resource進行抽象表示。
此處,已經(jīng)可以解釋文章探索實驗的結果:資源的獲取是靠Spring提供的DefaultResourceLoader實現(xiàn)的,它能夠實現(xiàn)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<Document> documents = loadDocuments(loader, name, resource);
// ...(省略)
List<Document> 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的配置文件優(yōu)先級更高。而一旦將配置項添加進environment的屬性源集合中,應用程序就能正確取讀到配置項。
// org.springframework.boot.context.config.ConfigFileApplicationListener.Loader#addLoadedPropertySources
private void addLoadedPropertySources() {
MutablePropertySources destination = this.environment.getPropertySources();
List<MutablePropertySources> loaded = new ArrayList<>(this.loaded.values());
Collections.reverse(loaded);
String lastAdded = null;
Set<String> 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類的配置文件優(yōu)先級最高,當配置項沖突時,總是"覆蓋"一切非profile的配置文件
總結
本文開篇提出一個問題:在依賴的公共Module的classpath放置application.properties,Spring Boot應用能否正確讀?。恐笸ㄟ^案例進行實驗,證明了此行為的可行性。為了了解Spring Boot對application.properties加載的過程,先是閱讀了Spring Boot 官方文檔對application.properties的介紹,并對其中關于配置項優(yōu)先級的模糊描述做了進一步的解釋。接著從源碼的角度,對application.properties的加載過程從頭到尾簡單介紹了一遍,了解到ResourceLoader及其默認實現(xiàn)類DefaultResourceLoader正是用于從classpath加載資源,因此能成功加載內嵌jar包中位于classpath的application.properties
最后,介紹了Spring Boot對于PropertySource優(yōu)先級處理的原則:后贏策略(last-wins),加載的過程按代碼定義的順序先加載,放入數(shù)據(jù)源之前進行倒置(reverse)放入,在后邊的反而優(yōu)先級高
題外話
1、配置文件前2優(yōu)先級位置分別是:file:./config/、file:./,在IDEA中是指當前項目的/config目錄以及當前項目根目錄。如果是多module項目,那么當前項目指的是父module目錄。其實在IDEA環(huán)境中使用這倆位置的配置文件意義不大,更多的,是與發(fā)布系統(tǒng)結合,發(fā)布系統(tǒng)將服務打成Executable Jar之后,將應用相關的基礎配置信息(如server.port、Apollo apollo.meta\env )配置在./config/或者./,用以覆蓋項目內有可能誤配或漏配的選項
2、本文的一些規(guī)律,不單適用于application.properties,還適用于別的配置文件。例如:配置項優(yōu)先級原則,基本思想是:由Spring加載所有的屬性源到Environment中,通過屬性源的方式將配置項進行隔離,不同的屬性源互不干擾,在此基礎上,靠前的屬性源的配置項優(yōu)先級高。這種行為是Spring默認的行為,該行為定義在PropertySourcesPropertyResolver,也意味著,我們可以自定義PropertyResolver,來改變這種默認的行為,實現(xiàn)自定義的優(yōu)先級順序,達到我們的目的
3、關于application.properties的加載過程,還有很多細節(jié)未曾提及,這并非意味著不重要,而是一篇文章難以面面俱到,而陷入源碼細節(jié)容易一葉障目。從問題出發(fā),梳理主干脈絡,把握核心思想,是為首要條件,之后每次根據(jù)需要,像剝洋蔥般一層層深入,能更容易掌握知識
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關文章
Windows10系統(tǒng)下修改jar中的文件并重新打包成jar文件然后運行的操作步驟
這篇文章主要介紹了Windows10系統(tǒng)下修改jar中的文件并重新打包成jar文件然后運行的操作步驟,文中通過圖文結合的形式給大家講解的非常詳細,對大家的學習或工作有一定的幫助,需要的朋友可以參考下2024-08-08

