Spring : Spring加载配置文件classpath、classpath*、file解析

目录

背景

最近研究dubbo这个框架遇到一个问题，dubbo的生产者都是通过jar来启动的，结合公司的项目都是通过war启动的，war包启动可以在war解压以后运维人员更改配置文件(原则上生产环境的配置只有运维人员才能看到)。但是jar包不可能让运维人员解压更改配置才从新打jar包。所以jar包启动的项目需要能够让运维人员方便快捷的更改配置。解决方案是将配置文件放在jar包外面。spring加载外部配置文件。

前缀	说明
classpath	优先本项目class路径查找，没有的话依次在其他jar包中class路径查找，找到第一个匹配的为止
classpath*	加载到所有class路径下的配置文件，包括jar包的class路径下，最终加载所有匹配的
file	通过URL加载，来源为文件系统（注意文件读取权限）
http	通过URL加载，来源为网络
(none)	根据 ApplicationContext 进行判断（这个我没试过）

classpath

<context:property-placeholder location="classpath:system.properties" />

举个栗子：A项目中resources中存在system.properties，B项目中resources中也存在system.properties。A项目以jar包形式引入B项目。此时A项目spring配置classpath:system.properties加载到的是A项目自己的system.properties。但是如果A项目resources中没有system.properties则最终结果加载到的是B.jar中的system.properties

classpath*

<context:property-placeholder location="classpath*:system.properties" />

举个栗子：A项目中resources中存在system.properties，B项目中resources中也存在system.properties。A项目以jar包形式引入B项目。此时A项目spring配置classpath*:system.properties加载到的是A和B的system.properties
如下图（我是引入的两个jar都有同名配置文件）：

这里大家可能会有疑问，同时引入了两个同名配置文件，如果两个同名配置文件中有同样的配置，比如:
A项目system.properties

milo=a
milo1=a

B项目system.properties

milo=b
milo1=b

那么最终引用的是哪个？我这边最终实验结果是根据spring加载顺序倒叙加载，直到找到匹配的值。而且值与值之间不影响，每次都按加载顺序倒叙查找。即：如果spring加载顺序为A->B ,那么最终取到的值为：milo=b milo1=b。而且spring在取milo和milo1时都是按照spring加载顺序倒叙取得。大家可以通过三个配置文件情况做下试验。对spring熟悉的同学也可找下源码看一下。

建议大家没有特殊需求不要用classpath*，因为加载越多效率越低

file

<context:property-placeholder location="file:/Users/mac/Desktop/IDEA Project/dubbodemo/dubbodemo-user-service/lc.properties" />

通过file我们可以将配置文件放在项目外边，这个标签也完美的解决文章最前边提到的运维人员更改jar包配置的问题。当然war包也可以这样配置。

通过JVM传参指定配置文件路径

最后讲一下结合JVM如何动态指定参数，配置文件路径最终一定是运维人员决定，所以配置文件参数我们要动态赋值，这里我们通过java -D{你的参数}方式将参数传给JVM

#/Users/mac/Desktop/lc.properties 这个参数大家注意中间不要有空格(比如文件夹名字有空格是可以的)，不然会被理解为两个参数
java -jar -Dlc=/Users/mac/Desktop/lc.properties dubbodemo-user-service-1.0-SNAPSHOT.jar 

Spring中引入lc这个参数

<context:property-placeholder location="file:${lc}" />

这样lc就可以传递给spring了，spring中引用方法和我们写在我们自己写的system.properties中的参数没什么区别。但是JVM的参数优先级别要比我们自己写的system.properties的优先级别要高。这里大家注意有限级别越高越先执行，匹配到了就不再向下执行了。environmentProperties，systemProperties，systemEnvironment的优先级别要大于用户的配置。哪怕用户配置<context:property-placeholder order="1"/>也是nvironmentProperties，systemProperties，systemEnvironment的优先级别更高。

详细解释大家可以参考：spring加载properties文件顺序