java - propertysourcesplaceholderconfigurer - ¿Es posible tener varios PropertyPlaceHolderConfigurer en mi applicationContext?

propertysourcesplaceholderconfigurer example

Question

Necesito cargar un archivo applicationContext.xml específico de acuerdo con una propiedad del sistema dada. Esto mismo carga un archivo con la configuración real. Por lo tanto, necesito 2 PropertyPlaceHolderConfigurer, uno que resuelve el parámetro del sistema y el otro dentro de la configuración real.

¿Alguna idea de como hacer esto?

Answer 1

Cuidado: puede haber un error relacionado con varios configuradores. Ver http://jira.spring.io/browse/SPR-5719 para más detalles.

No puedo hacer que múltiples trabajen localmente ... pero todavía no estoy culpando a nadie más que a mí.

Answer 2

No se puede hacer esto directamente, y esta edición de JIRA de Spring explica por qué (ver el comentario de Chris Beams para una explicación detallada):

jira.springsource.org/browse/SPR-6428

Sin embargo, sí proporciona una solución con Spring 3.1 o posterior, que consiste en utilizar la clase PropertySourcesPlaceholderConfigurer en lugar de la clase PropertyPlaceholderConfigurer.

Puede descargar un proyecto basado en Maven que demuestre el problema y la solución de Spring Framework emite github:

https://github.com/SpringSource/spring-framework-issues

Busque el número del problema, SPR-6428, en los proyectos descargados.

Answer 3

Otra solución es usar la propiedad placeholderPrefix de PropertyPlaceholderConfigurer. Usted lo especifica para el segundo (tercero, cuarto ...) configurador, y luego pone un prefijo a todos sus marcadores de posición correspondientes, por lo tanto no habrá conflicto.

<bean id="mySecondConfigurer"
        class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
        p:location="classpath:/myprops.properties" 
        p:placeholderPrefix="myprefix-"/>

<bean class="com.mycompany.MyClass" p:myprop="${myprefix-value.from.myprops}"/>

Answer 4

Por mi parte, jugando con PropertyPlaceholderConfigurer ambas propiedades:

• orden (debe ser menor para el PPC primero consultado / analizado)

• ignoreUnresolvablePlaceholders ("falso" para el PPC primero consultado / analizado, "verdadero" para el siguiente)

• y también otorgar 2 identificaciones distintas a ambos PPC (para evitar que uno sea sobrescrito por el otro)

funciona perfectamente

Espero eso ayude

Answer 5

Sí, puedes hacer más de uno. Asegúrese de establecer ignoreUnresolvablePlaceholders para que el primero ignore cualquier marcador de posición que no pueda resolver.

<bean id="ppConfig1" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
   <property name="ignoreUnresolvablePlaceholders" value="true"/>
   <property name="locations">
    <list>
             <value>classpath*:/my.properties</value>
    </list>
  </property>
</bean>

<bean id="ppConfig2" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
   <property name="ignoreUnresolvablePlaceholders" value="false"/>
   <property name="locations">
    <list>
             <value>classpath*:/myOther.properties</value>
    </list>
  </property>
</bean>

Dependiendo de su aplicación, debe investigar systemPropertiesMode, le permite cargar propiedades desde un archivo, pero permite que las propiedades del sistema anulen los valores en el archivo de propiedades, si está configurado.

Answer 6

Solo dándome 2 identificadores distintos funcionó para mí. Estoy usando la primavera 3.0.4.

Espero que ayude.

Answer 7

Tenemos el siguiente enfoque funcionando:

<util:properties id="defaultProperties">
    <prop key="stand.name">DEV</prop>
    <prop key="host">localhost</prop>
</util:properties>
<context:property-placeholder 
    location="file:${app.properties.path:app.properties}" 
    properties-ref="defaultProperties"/>

La propiedad del sistema app.properties.path se puede utilizar para anular la ruta al archivo de configuración.

Y la aplicación incluye algunos valores predeterminados para marcadores de posición que no se pueden definir con los valores predeterminados en los módulos comunes.