spring ----- context:property-placeholder/元素

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

--------------------------------------------------------------------------------------------------------------------------------------------------------

为什么需要这个参数？

1.有些参数在某些阶段中是常量

比如：a、在开发阶段我们连接数据库时的连接url，username，password，driverClass等

b、分布式应用中client端访问server端所用的server地址，port，service等

c、配置文件的位置

2.而这些参数在不同阶段之间又往往需要改变

比如：在项目开发阶段和交付阶段数据库的连接信息往往是不同的，分布式应用也是同样的情况。

期望：能不能有一种解决方案可以方便我们在一个阶段内不需要频繁书写一个参数的值，而在不同阶段间又可以方便的切换参数配置信息

解决：

只需要在spring的配置文件里添加一句：<context:property-placeholder location="classpath:jdbc.properties"/> 即可，

这里location值为参数配置文件的位置，参数配置文件通常放在src目录下，而参数配置文件的格式跟java通用的参数配置文件相同，即键值对的形式，

例如：

#jdbc配置

test.jdbc.driverClassName=com.mysql.jdbc.Driver
test.jdbc.url=jdbc:mysql://localhost:3306/test
test.jdbc.username=root
test.jdbc.password=root

应用：

1.这样一来就可以为spring配置的bean的属性设置值了，比如spring有一个jdbc数据源的类DriverManagerDataSource

在配置文件里这么定义bean：

--------------------------------------------------------------------------------------------------------------------------------------------

外在化应用参数的配置

在开发企业应用期间，或者在将企业应用部署到生产环境时，应用依赖的很多参数信息往往需要调整，比如LDAP连接、RDBMS JDBC连接信息。对这类信息进行外在化管理显得格外重要。使用PropertyPlaceholderConfigurer和PropertyOverrideConfigurer对象。

PropertyPlaceholderConfigurer实现了BeanFactoryPostProcessor接口，它能够对<bean/>中的属性值进行外在化管理。开发者可以提供单独的属性文件来管理相关属性。

比如，userinfo.properties文件：

db.username=scott
db.password=tiger

propertyplaceholderconfigurer.xml。正常情况下，在userInfo的定义中不会出现${db.username}、${db.password}等类似信息，这里采用PropertyPlaceholderConfigurer管理username和password属性的取值。DI容器实例化userInfo前，PropertyPlaceholderConfigurer会修改userInfo的元数据信息（<bean/>定义），它会用userinfo.properties中db.username对应的scott值替换${db.username}、db.password对应的tiger值替换${db.password}。最终，DI容器在实例化userInfo时，UserInfo便会得到新的属性值，而不是${db.username}、${db.password}等类似信息。

PropertyPlaceholderConfigurer内置的功能非常丰富，如果它未找到${xxx}中定义的xxx键，它还会去JVM系统属性（System.getProperty()）和环境变量（System.getenv()）中寻找。通过启用systemPropertiesMode和searchSystemEnvironment属性，开发者能够控制这一行为。

----------------------------------------------------------------------------------------------------------------------------------------------------

详细参数解析

众所周知，Spring容器是采用反射扫描的发现机制，通过标签的命名空间实例化实例，当Spring探测到容器中有一个org.springframework.beans.factory.config.PropertyPlaceholderCVonfigurer的Bean就会停止对剩余PropertyPlaceholderConfigurer的扫描，即只能存在一个实例！

<context:property-placeholder   
        location=""  
        file-encoding=""  
        ignore-resource-not-found=""  
        ignore-unresolvable=""  
        properties-ref=""  
        local-override=""  
        system-properties-mode=""  
        order=""  
/>

location：表示属性文件位置，多个之间通过如逗号/分号等分隔；
file-encoding：文件编码；
ignore-resource-not-found：如果属性文件找不到，是否忽略，默认false，即不忽略，找不到将抛出异常
ignore-unresolvable：是否忽略解析不到的属性，如果不忽略，找不到将抛出异常
properties-ref：本地java.util.Properties配置
local-override：是否本地覆盖模式，即如果true，那么properties-ref的属性将覆盖location加载的属性
system-properties-mode：系统属性模式，ENVIRONMENT（默认），NEVER，OVERRIDE
ENVIRONMENT：将使用Spring 3.1提供的PropertySourcesPlaceholderConfigurer，其他情况使用Spring 3.1之前的PropertyPlaceholderConfigurer
OVERRIDE： PropertyPlaceholderConfigurer使用，因为在spring 3.1之前版本是没有Enviroment的，所以OVERRIDE是spring 3.1之前版本的Environment
NEVER：只查找properties-ref、location；

order：当配置多个<context:property-placeholder/>时的查找顺序

----------------------------------------------------------------------------------------------------------------------------------------------------

使用参数时注意事项：

1.location中的加载文件的顺序

将依次加载，值得注意的是如果后一个文件中有和前面某一个文件中属性名是相同的，最终取的值是后加载的值

举例来说：

如果location中有多个文件：
classpath:db.properties,classpath:default.properties,classpath:default3.properties,classpath:default2.properties

default.properties文件中有个属性名userId，其对应的值为-1
default2.properties文件中也有一个属性名userId，其对应的值为-2
default3.properties文件中特有一个属性名userId，其对于那个的值为-3

default.properties文件先加载，此时userId的值为-1，当default3.properties文件加载时将更新原来的值，此时userId的值为-3，同理，最后加载default2.properties文件，所以userId最终值为-2

所以需要避免不同属性文件中的属性名称重名

2.ignore-resource-not-found和ignore-unresolvable两个属性是类似的作用，推荐配对使用

如果location中的文件指向了一个不存在的文件，那么也极有可能意味着有属性无法解析（虽然存在其他属性文件中存在重名，但是这个是应该避免的）

所以当ignore-resource-not-found设为true时，ignore-unresolvable也必须设为true，其实当ignore-unresolvable设为true时，ignore-resource-not-found的值true或false，并不影响异常的抛出

如果设置为ture，后属性值无法解析成功，将赋值为${属性名}

不推荐将ignore-resource-not-found和ignore-unresolvable的值设置为ture，默认为false，可以有效避免程序运行异常

3.properties-ref属性

引入其他方式引入的属性文件

<bean id="refProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="locations">
        <list>
            <value>classpath:default2.properties</value>
        </list>
    </property>
</bean>

该属性需要local-override配合使用，只有当local-override属性值为true时，properties-ref属性文件中属性值将覆盖location属性文件属性值（同名属性）

4.local-override属性

当local-override属性值为true时，properties-ref属性文件中属性值将覆盖location属性文件属性值（同名属性）

5.sytem-properties-mode属性

不同的sytem-properties-mode属性定义了不同的查找顺序
Environment环境：包括JDK环境，系统环境变量，Sevlet环境，Spring环境等，是Spring在3.1之后抽象的一个表示环境配置

在local-override属性值为false，sytem-properties-mode属性值为ENVIRONMENT或OVRRIDE时，查找顺序是location，然后是environment或者System.getProperty(),System.getenv()（Spring 3.1 之前）
即现加载location指向的属性文件，再加之environment指向的环境，当environment环境中存在和location指向的属性文件中同名的属性，则该属性的值将被修改，取决于environment环境中的值
如果sytem-properties-mode属性值为NEVER，则只查询location指向的属性文件

当local-override属性值为true时，最后将加载properties-ref指向的文件，如遇到同名的，该同名属性值将取决于properties-ref指向的文件中的值

所以，最终程序中获取的值将是一个综合作用后的值，一般情况下建议sytem-properties-mode属性值为NEVER避免ENVIRONMENT环境中的不可控

----------------------------------------------------------------------------------------------------------------------------------------------------

参考：https://blog.csdn.net/superdog007/article/details/41825355

参考： https://blog.csdn.net/Rickesy/article/details/50791534

spring ----- context:property-placeholder/元素

猜你喜欢