自定义PropertyPlaceHolder无法完成替换任务

本文介绍了如何在Spring环境中解决PropertyPlaceholderConfigurer与MyBatis自动扫描时导致的配置文件引用失效问题。通过配置自定义PropertyPlaceholderConfigurer并调整自动扫描配置,实现了从XML配置文件中正确读取并替换bean占位符,同时确保了MyBatis的正常运行。

 Spring默认的PropertyPlaceholderConfigurer只能加载properties格式的配置文件,现在需要完成让其支持可以从类似hadoop格式的xml配置文件中读取配置信息,并替换掉相关bean中的占位符,对其进行了扩展,具体扩展如下:

public class CustomPropertyPlaceholderConfigurer extends PropertyPlaceholderConfigurer {
    private Resource[] locations;

    public void loadProperties(Properties props) throws IOException {
        if (this.locations != null) {
            PropertiesPersister propertiesPersister = new DefaultPropertiesPersister();
            for (int i = 0; i < this.locations.length; i++) {
                Resource location = this.locations[i];
                if (logger.isInfoEnabled()) {
                    logger.info("Loading properties file from " + location);
                }
                InputStream is = null;
                try {
                    is = location.getInputStream();
                    propertiesPersister.load(props, is);

                    Configuration conf = SquirrelConfiguration.create();
                    Map<String, String> map = conf.listAllConfEntry();  // 从squirrel-site.xml中读取配置信息
                    for (Map.Entry<String, String> entry : map.entrySet()) {
                        props.put(entry.getKey(), entry.getValue());
                    }
                } finally {
                    if (is != null) is.close();
                }
            }
        }
    }

    public void setLocations(Resource[] locations) {
        super.setLocations(locations);
        this.locations = locations;
    }

}




但是运行却一直报错,${jdbc_driver_name}没有被替换,通过查询发现,原来是在spring里使用org.mybatis.spring.mapper.MapperScannerConfigurer 进行自动扫描的时候,设置了sqlSessionFactory 的话,可能会导致PropertyPlaceholderConfigurer失效,也就是用${jdbc_driver_name}这样之类的表达式,将无法获取到properties文件里的内容。 导致这一原因是因为,MapperScannerConigurer实际是在解析加载bean定义阶段的,这个时候要是设置sqlSessionFactory的话,会导致提前初始化一些类,这个时候,
PropertyPlaceholderConfigurer还没来得及替换定义中的变量,导致把表达式当作字符串复制了。 但如果不设置sqlSessionFactory 属性的话,就必须要保证sessionFactory在spring中名称一定要是sqlSessionFactory ,否则就无法自动注入。又或者直接定义MapperFactoryBean ,再或者放弃自动代理接口方式。
可以如下方式修改:
<bean id="propertyConfigurer"  class="com.yowu.common.CustomPropertyPlaceholderConfigurer">
        <property name="locations">
            <list>
                <value>classpath:important.properties</value>
            </list>
        </property>
     </bean>

	<!-- 配置线程池 -->
	<bean id="taskExecutor"
		class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
		<!-- 线程池维护线程的最少数量 -->
		<property name="corePoolSize" value="10" />
		<!-- 线程池维护线程所允许的空闲时间 -->
		<property name="keepAliveSeconds" value="0" />
		<!-- 线程池维护线程的最大数量 -->
		<property name="maxPoolSize" value="10" />
		<!-- 线程池所使用的缓冲队列 -->
		<property name="queueCapacity" value="0" />
	</bean>

	<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
		<property name="driverClassName" value="${squirrel_jdbc_driver}" />
		<property name="url" value="${squirrel_jdbc_url}" />
		<property name="username" value="${squirrel_jdbc_username}" />
		<property name="password" value="${squirrel_jdbc_password}" />
		<property name="validationQuery" value="select 1" />
		<property name="initialSize" value="5" />
		<property name="testWhileIdle" value="true" />
		<property name="maxIdle" value="20" />
		<property name="minIdle" value="5" />
		<property name="maxActive" value="50" />
		<property name="removeAbandonedTimeout" value="180" />
		<property name="maxWait" value="30000" />
	</bean>

    <bean id="ysqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
        <property name="dataSource" ref="dataSource"/>
        <property name="mapperLocations" >
            <list>
                <value>classpath*:mybatis/*.xml</value>
            </list>
        </property>
    </bean>
    <bean id="sqlSession" class="org.mybatis.spring.SqlSessionTemplate">
        <constructor-arg index="0" ref="ysqlSessionFactory"></constructor-arg>
        <constructor-arg index="1" value="BATCH"></constructor-arg>
    </bean>

    <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
        <property name="basePackage" value="com.yowu.dao, com.yowu.app.repository.dao"/>
        <!--核心就是添加下面一句。后面那个属性是value,不是ref,切记-->
        <property name="sqlSessionFactoryBeanName" value="ysqlSessionFactory" />
    </bean>


通过查看MapperScannerConfigurer源码发现,其实有这么一段代码:

public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry beanDefinitionRegistry) throws BeansException {
    if (this.processPropertyPlaceHolders) {
      processPropertyPlaceHolders();
    }

    Scanner scanner = new Scanner(beanDefinitionRegistry);
    scanner.setResourceLoader(this.applicationContext);

    scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
  }

  /*
   * BeanDefinitionRegistries are called early in application startup, before
   * BeanFactoryPostProcessors. This means that PropertyResourceConfigurers will not have been
   * loaded and any property substitution of this class' properties will fail. To avoid this, find
   * any PropertyResourceConfigurers defined in the context and run them on this class' bean
   * definition. Then update the values.
   */
  private void processPropertyPlaceHolders() {
大概意思是可以设置processPropertyPlaceHolders为true,强制让PropertyResourceConfigure执行下替换工作,大家不妨试一下,不失为一个优雅的解决方案。

<think>好的,我现在需要解决用户的问题:在自定义PropertyPlaceholder的情况下,为什么Environment.getProperty能解密而@Value注解不能解密。我需要先理解这两个机制是如何工作的,然后找出它们之间的差异导致解密结果不同的原因。 首先,用户提到了Spring中的Environment和@Value注解的使用。根据引用[2]和引用[3],Environment接口可以读取通过@PropertySource加载的属性,而@Value则是用来注入这些属性的。问题出现在自定义PropertyPlaceholder的情况下,可能涉及到属性占位符的处理和解密。 接下来,我需要回忆Spring中属性处理的过程。通常,@PropertySource会将属性文件加载到Environment中。当使用@Value时,Spring会通过PropertySourcesPlaceholderConfigurer来处理占位符替换。如果用户自定义PropertyPlaceholder,比如重写了解密逻辑,可能会影响这个处理流程。 现在的问题是,为什么Environment.getProperty能正确解密,而@Value不行。可能的原因在于两者的处理时机或使用的组件不同。Environment.getProperty可能直接访问已经处理过的属性值,而@Value的解析可能在自定义PropertyPlaceholderConfigurer之前或之后,导致解密逻辑未被应用。 另外,根据引用[3],EnvironmentAware可以通过Environment对象获取属性,这可能绕过了某些占位符处理的步骤。而@Value依赖的是PropertySourcesPlaceholderConfigurer,如果自定义的占位符配置没有正确配置,可能导致@Value无法应用解密逻辑。 可能的解决方案包括检查自定义PropertyPlaceholderConfigurer的配置,确保它能够处理@Value的占位符,或者在解密时使用统一的处理器。另外,可能需要确保自定义的解密逻辑被正确集成到Spring的属性解析链中。 需要进一步验证这些假设,例如,查看自定义PropertyPlaceholderConfigurer是否被正确注册,是否覆盖了默认的配置,以及解密逻辑是否在适当的时候执行。此外,可能涉及Bean的加载顺序问题,导致@Value在占位符处理时未能应用解密。</think>在自定义 `PropertyPlaceholder` 的情况下,`Environment.getProperty` 能解密而 `@Value` 注解无法解密的原因主要与 **属性解析的时机** 和 **处理器的注册顺序** 有关。以下是详细分析及解决方案: --- ### **原因分析** 1. **属性解析流程差异** - `Environment.getProperty` 直接通过 `Environment` 对象获取属性值,而 `Environment` 中的属性值在加载时可能已经通过自定义的 `PropertyPlaceholder` 完成了解密处理[^2][^3]。 - `@Value` 注解的解析依赖于 `PropertySourcesPlaceholderConfigurer`,若自定义的 `PropertyPlaceholder` 未正确集成到该处理器中,`@Value` 的占位符(如 `${xxx}`)将无法触发解密逻辑。 2. **处理器注册顺序** - 如果自定义的 `PropertyPlaceholder`(例如继承 `PropertySourcesPlaceholderConfigurer` 的类)未在 Spring 容器中优先注册,可能导致 `@Value` 注解的解析过早使用默认处理器,跳过解密步骤。 3. **占位符处理范围** - 自定义的 `PropertyPlaceholder` 可能仅针对 `Environment` 中的原始值进行解密,而未覆盖 `@Value` 注解的占位符解析流程。 --- ### **解决方案** #### 1. **统一属性处理器** 确保自定义的 `PropertyPlaceholder` 同时处理 `Environment` 和 `@Value` 的占位符。 **示例代码**: ```java @Configuration public class CustomPropertyConfig extends PropertySourcesPlaceholderConfigurer { @Override protected String resolvePlaceholder(String placeholder, PropertySources propertySources) { String value = super.resolvePlaceholder(placeholder, propertySources); return decryptValue(value); // 调用自定义解密逻辑 } private String decryptValue(String encryptedValue) { // 实现解密逻辑(如 AES 解密) return decryptedValue; } } ``` 通过继承 `PropertySourcesPlaceholderConfigurer` 并重写 `resolvePlaceholder` 方法,确保所有占位符(包括 `@Value`)均经过解密。 --- #### 2. **显式注册自定义处理器** 在配置类中手动注册自定义的 `PropertySourcesPlaceholderConfigurer`,确保其优先级高于默认处理器。 **示例代码**: ```java @Bean public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() { return new CustomPropertyConfig(); // 返回自定义的处理器 } ``` --- #### 3. **验证 Bean 加载顺序** 确保自定义处理器在 `@Value` 注解的 Bean 初始化之前加载。可通过 `@DependsOn` 注解强制依赖关系: ```java @Configuration @DependsOn("customPropertyConfig") // 依赖自定义处理器 public class AppConfig { // 其他 Bean 定义 } ``` --- #### 4. **调试与日志验证** 在自定义处理器的 `resolvePlaceholder` 方法中添加日志,确认 `@Value` 占位符是否触发解密逻辑: ```java @Override protected String resolvePlaceholder(String placeholder, PropertySources propertySources) { logger.info("Resolving placeholder: {}", placeholder); // ... 解密逻辑 } ``` --- ### **总结** - **核心问题**:`@Value` 的解析依赖 `PropertySourcesPlaceholderConfigurer`,若自定义逻辑未正确覆盖该处理器,则解密不生效。 - **关键步骤**:通过继承并重写 `PropertySourcesPlaceholderConfigurer`,统一处理 `Environment` 和 `@Value` 的占位符解析,确保解密逻辑一致。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值