Primavera 3.1 PropertySourcesPlaceholderConfigurer e importación condicional

Question

En cuanto a la nueva compatibilidad propiedad elástica de 3,1 (http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/), parece que esto debería ser posible:

<context:property-placeholder location="/WEB-INF/application-customer-dev.properties,classpath:application-customer.properties" ignore-resource-not-found="true"/> 

<import resource="classpath*:com/x/core/security/security-${login.security}.xml"/> 

donde login.security está en application-customer-dev.properties como:

login.security=dev 

(y security-dev.xml existe en el lugar apropiado). Sin embargo, me falta algo, ya que login.security no se puede resolver. Esperaría este comportamiento en versiones de la primavera anterior a 3.1, pero parece que esto debería ser válido con 3.1 (que estamos usando)?

Answer 1

Nota al pie [2] de su enlace:

[2]: Dado que el procesamiento de <import/> elementos necesariamente se produce antes de que se invocan BeanFactoryPostProcessors, lo que significa que incluso PropertyPlaceholderConfigurer no podía ayudar aquí. Debido a que el entorno y su conjunto de PropertySources se configuran antes de la actualización del contenedor, los marcadores de posición en los elementos se pueden resolver contra el entorno sin ningún problema de ciclo de vida.

ACTUALIZACIÓN:

De acuerdo con la javadoc for PropertySourcesPlaceholderConfigurer, PropertySourcesPlaceholderConfigurer es un BeanFactoryPostProcessor, así que lo que la nota realmente dice es que la importación se resuelve antes la PropertySourcesPlaceholderConfigurer está instalado, por lo que no funcionará cualquiera (De hecho, en el momento en que se resuelve el <import/>, ¡el configurador podría no existir aún!) Sí, cuando esté instalado verá el Environment, pero no podrá usarlo para resolver dentro de un <import/>, porque en ese momento no postprocesadores están operativos Y eso incluye PropertySourcesPlaceholderConfigurer.

Básicamente configuración contexto XML Spring va más o menos así: se crea

1. Contexto.
2. Environment está establecido.
3. Se lee XML (todo XML, resolviendo las importaciones si es necesario). Se crean definiciones de frijoles
4. BeanFactoryPostProcessor s se instalan e invocan, procesando las definiciones de bean.
5. BeanPostProcessor s instalados.
6. Los beans se crean instancias de acuerdo con las definiciones de bean. BeanPostProcessors se aplican.

Se trata de un problema similar como lo que hace que no se puede utilizar la propiedad order de muchos post-procesadores para aplicar una BeanPostProccesor ante un BeanFactoryPostProcessor (para hacer algo como hacer un PropertyPlaceholderConfigurer marcadores de posición a resolver de una @PersistenceContext): el comportamiento es codificado en el contexto de la aplicación Spring, por lo que debe solucionarlo especializando algunas clases de Spring.

Answer 2

Creo que está leyendo mal el blog un poco @Kurt - Se debe resolver SI la fuente de propiedad que contiene la propiedad está presente antes de que las definiciones de bean comiencen a crearse.

Así que la manera de conseguir su importación a resolver serán estas dos maneras: 1. establecer una variable de entorno con este parámetro (-Dlogin.security=dev) que se registrará como una fuente de propiedad por defecto
2. registrar un archivo como una propiedad fuente programáticamente, se menciona en el artículo de blog escribiendo una costumbre ApplicationContextInitializer para registrar su fuente de propiedad - que debería ser capaz de utilizar una ResourcePropertySource para registrar su basado en archivos fuente de la propiedad

Answer 3

debería ser mucho más fácil de lo que necesita ahora por @Inject Environment y usando perfiles. No debería necesitar reemplazar parte de un nombre de archivo.