Estrategias comunes para definir los granos de primavera para diferentes entornos

Question

¿Cuáles son las estrategias comunes para definir un grupo de granos, que se usan de forma diferente en los entornos de desarrollo y producción?

Digamos que tengo 2 beans, cada uno implementando la misma interfaz. Un bean sirve como abstracción para el sistema de archivos local, el otro se conecta a un sistema de archivos distribuido. Para mantener el desarrollo lo más estable posible, el entorno de desarrollo debe usar la implementación del sistema de archivos local, la versión de producción usa beans distribuidos del sistema de archivos.

Actualmente, lo que estoy haciendo es tener dos definiciones xml.

native.xml

<bean id="resourceSystem" class="com.cust.NativeResourceSystem" /> 

distributed.xml

<bean id="resourceSystem" class="com.cust.HadoopResourceSystem"> 
    <constructor-arg name="fs" ref="hdfs" /> 
</bean> 

Al crear contexto de aplicación Omito ya sea native.xml o distributed.xml en función del entorno y agarrar el frijol resourceSystem.

¿Existen herramientas adecuadas o mejores prácticas en Spring para configurar las definiciones de beans para diferentes entornos?

Gracias.

Answer 1

Aquí va lo que la documentación de referencia de Primavera dice acerca PropertyPlaceholderConfigurer

El PropertyPlaceholderConfigurer no busca propiedades sólo en las propiedades archivo que especifique, pero también comprueba contra las propiedades del sistema Java si no puede encontrar una propiedad que estás tratando de usar.

Como se puede ver arriba puede configurar una propiedad del sistema Java

En el equipo de desarrollo

-Dprofile=development 

En la máquina de producción

-Dprofile=production 

Así se puede definir una configuración global de contexto de la aplicación que importa cada contexto en capas justes de la siguiente manera

<?xml version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans" 
     xmlns:context="http://www.springframework.org/schema/context" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://www.springframework.org/schema/beans 
          http://www.springframework.org/schema/beans/spring-beans-2.5.xsd 
          http://www.springframework.org/schema/context 
          http://www.springframework.org/schema/context/spring-context-2.5.xsd"> 
    <context:property-placeholder/> 
    <import resource="service-${profile}.xml"/> 
    <import resource="persistence-${profile}.xml"/> 
    <import resource="security-${profile}.xml"/> 
</beans> 

Tenga en cuenta todas las vías de ubicación son en relación con el archivo de definición que hace la importación

Por lo tanto, este tipo de configuración es compatible con la primavera

Por lo general, es preferible mantener un direccionamiento indirecto para dichas ubicaciones absolutas, por ejemplo, a través de los marcadores de posición "$ {...}" que se resuelven contra las propiedades del sistema JVM en tiempo de ejecución.

Answer 2

Esto es lo que he estado usando en muchos de mis proyectos. Tenga todos los beans independientes de su entorno en, por ejemplo, common.xml y todos los demás en decir dev.xml/qa.xml/prod.xml. Si usa ant para construir su proyecto, proporcione el entorno como argumento para el proceso de compilación y permita que el script de compilación incluya env.xml apropiado y omita otros. Quiero decir, la secuencia de comandos de compilación copiará dev.xml como env.xml si es un entorno de desarrollo o qa.xml como env.xml si es un control de calidad. Entonces, el código que carga las definiciones de bean siempre usará "common.xml, env.xml".

Answer 3

Esta funcionalidad está en el radar de SpringSource, y está programada para futuras versiones.

Ver here y here.