Spring Boot加载application.propert

作者: ZX_周雄 | 来源:发表于2019-12-16 13:22 被阅读0次

背景

基于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).

也即是说，排在前边的优先级高于排在后边的。这里有几层隐含的含义，在官方文档中并没有表述清楚，为方便记忆与理解，总结如下：

上边的4个位置均可放置配置文件(application.properties)，它们之间是一个并集关系而不是互斥关系，Spring Boot 默认都会加载到它们，而不是加载到高优先级的配置文件之后就停止加载低优先级的
如果在两个以上的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);
        // 创建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);
    // 发布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) {
    // 发布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<>();
    // 以上四个变量默认状态为空集合或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<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方法执行完毕之后，只要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的顺序进行搜索，而搜索顺序反应的是配置项的优先级，在上边已提过，不再赘述

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机制对实现类进行加载，默认实现类有两个

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的默认实现类，能够获取classpath资源以及URL资源或类URL资源，资源用Resource进行抽象表示。

此处，已经可以解释文章探索实验的结果：资源的获取是靠Spring提供的DefaultResourceLoader实现的，它能够实现classpath的扫描，进而加载资源，因此，只要是classpath下的配置文件，无论是否在内嵌jar包内，最终都能加载到

有了Loader，以及Resource，就可以进行资源的加载，加载的结果是List<Document>，代表对配置文件属性源的抽象以及封装。用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的配置文件优先级更高。而一旦将配置项添加进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类的配置文件优先级最高，当配置项冲突时，总是"覆盖"一切非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)放入，在后边的反而优先级高

题外话

配置文件前2优先级位置分别是：file:./config/、file:./，在IDEA中是指当前项目的/config目录以及当前项目根目录。如果是多module项目，那么当前项目指的是父module目录。其实在IDEA环境中使用这俩位置的配置文件意义不大，更多的，是与发布系统结合，发布系统将服务打成Executable Jar之后，将应用相关的基础配置信息（如server.port、Apollo apollo.meta\env ）配置在./config/或者./，用以覆盖项目内有可能误配或漏配的选项
本文的一些规律，不单适用于application.properties，还适用于别的配置文件。例如：配置项优先级原则，基本思想是：由Spring加载所有的属性源到Environment中，通过属性源的方式将配置项进行隔离，不同的属性源互不干扰，在此基础上，靠前的属性源的配置项优先级高。这种行为是Spring默认的行为，该行为定义在PropertySourcesPropertyResolver，也意味着，我们可以自定义PropertyResolver，来改变这种默认的行为，实现自定义的优先级顺序，达到我们的目的
关于application.properties的加载过程，还有很多细节未曾提及，这并非意味着不重要，而是一篇文章难以面面俱到，而陷入源码细节容易一叶障目。从问题出发，梳理主干脉络，把握核心思想，是为首要条件，之后每次根据需要，像剥洋葱般一层层深入，能更容易掌握知识

Spring Boot加载application.propert

背景

探索

原理分析

注：下边的源码基于Spring Boot 2.1.10.RELEASE

总结

题外话

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Spring