Cambiar la configuración de correo electrónico de Spring según el modo dev/test/prod

Question

A menudo pruebo mi aplicación con una copia de una base de datos en vivo, pero tengo que tener cuidado de no realizar ninguna acción que provoque que se envíe un correo electrónico a un usuario. Me encantaría tener una forma de configurar la primavera para que cuando esté en el modo de desarrollo o prueba, no se envíe ningún correo electrónico a los usuarios reales. Idealmente, me gustaría que todos los correos electrónicos que deberían haber ido al usuario vayan a un buzón que pueda examinar. Y no quiero cambiar ningún código para que esto suceda, solo archivos de configuración xml.

Ya estoy usando PropertyPlaceholderConfigurer y estoy leyendo en diferentes archivos de propiedades en función de si estoy ejecutando en producción, prueba o modos de desarrollo. Configuro un JavaMailSenderImpl basado en valores en el archivo de propiedades. También estoy usando SimpleMailMessage para crear una plantilla con la dirección De.

Idealmente, habría una manera de reescribir a la dirección TO de todos los correos electrónicos salientes a una cuenta de prueba si estoy ejecutando en modo dev o prueba.

Mi primer pensamiento fue utilizar un servidor SMTP diferente para el desarrollo y la prueba. Pero también tendría que administrar otro servidor de correo y debería personalizarlo para que no envíe correo a ninguna parte, sino que lo envíe a un solo buzón. No quiero agregar más requisitos de administración si es posible.

Quizás esa sea la mejor solución, pero parece que debería haber una forma de interceptar los correos electrónicos y cambiar el destinatario.

¿Alguien ha solucionado este problema anteriormente? ¿Qué soluciones se te ocurrieron?

Answer 1

Veo que indica un requisito específico de que no desea cambiar ningún código. Todavía me gustaría sugerir la creación de una implementación de código auxiliar de JavaMailSender. De esta forma, podría inyectar el objeto stub en sus versiones de desarrollo y prueba.

Answer 2

Eche un vistazo a mock-javamail (hace lo que sugiere la respuesta anterior) o una solución posiblemente incluso más rápida es un servidor SMTP falso como Fakemail.

Answer 3

He tenido un requisito similar en el pasado, y mi solución fue escribir lo que llamé EnvironmentSelectingFactoryBean (Spring parece alentar nombres de clase larga ...). Esta fue una implementación de FactoryBean que "seleccionaría" uno de los rangos disponibles en función del entorno de aplicación actual.

Si te muestro algunos ejemplos de XML, creo que obtendrá la idea:

<bean id="mailSender" class="com.kizoom.spring.config.EnvironmentSelectingFactoryBean"> 
    <property name="beanMap"> 
     <map> 
     <entry key="test"> 
      <bean class="org.springframework.mail.javamail.JavaMailSenderImpl"> 
       <property name="host" value="${mailhost.test}"/> 
      </bean> 
     </entry> 
     <entry key="production"> 
      <bean class="org.springframework.mail.javamail.JavaMailSenderImpl"> 
       <property name="host" value="${mailhost.production}"/> 
      </bean> 
     </entry> 
     </map> 
    </property> 
</bean> 

Así, EnvironmentSelectingFactoryBean sabe si se está ejecutando en el modo de "producción" "prueba" o, recoge la adecuada bean del beanMap, y escupe eso desde su método FactoryBean.getObject(). Ambos beans en el beanMap son remitentes de correo reales, no stubs, cada uno con diferentes valores de marcador de propiedad, pero nunca corre el riesgo de obtener el incorrecto.

El código del cliente verá un solo JavaMailSender bean.

Answer 4

Nota: mi respuesta se basa en el uso de Maven, así que esto es más sobre la construcción que nada, pero el uso de la primavera me permite inyectar los valores convenientemente.

Puedo usar un property-placeholder y construir en granos como:

JDBC.propiedades:

db.url=hostname:1521/test 
db.username=awesome 
db.password=password 

applicationContext.xml (usando espacio de nombres contexto)

<context:property-placeholder location="classpath:jdbc.properties"/> 
<bean id="yo" class="some.DataSource"> 
    <property name="url" value="${db.url}"/> 
    <property name="username" value="${db.username}"/> 
    <property name="password" value="${db.password}"/> 
</bean> 

Entonces almacenar los entornos en carpetas independientes con valores específicos de dominio como:

src/main/environments 
++ prod 
+++++ jdbc.properties 
++ dev 
+++++ jdbc.properties 
++ cert 
+++++ jdbc.properties 

utilizando perfiles de Maven (de pom.xml):

<profile> 
    <id>environment</id> 
    <activation> 
     <property> 
      <name>environment</name> 
     </property> 
    </activation> 
    <build> 
     <resources> 
      <resource> 
       <directory>src/main/environments/${environment}</directory> 
      </resource> 
     </resources> 

Puede ejecutar cualquier comando experto con la propiedad -Denviroment para flexionar las propiedades:

mvn clean -Denvironment=dev test 
mvn clean -Denvironment=cert package 
mvn clean -Denvironment=prod deploy 

etc y todos los archivos de esa carpeta ambiente se copian en el destino o artefacto junto con cualquier archivo src/main/resources.

Answer 5

Otra opción con la propiedad Place titular es cargar dinámicamente un archivo de propiedades dependiendo de la propiedad del sistema en tiempo de ejecución.

/WEB-INF/config/myapp.${myapp.env}.properties

WEB-INF/conf tendrá myapp.prod.properties myapp.stag.properties miaplicacion .test.properties

Añadir -Dmyapp.env = estímulo para el gato o usted servidores de aplicaciones puesta en marcha de la escritura.

Answer 6

La mejor solución es crear javax.mail.Session como recurso JNDI. De lo que puede configurarlo de manera diferente para prod/prueba y dev. Y no tiene que preocuparse por cambiar la configuración en su aplicación, ya que el servidor solo administra la diferencia.

Para dev * y ** prueba Puedo recomendarle un buen simulacro de javax.mail.Session.

Un proyecto github javaMail extension añade transporte archivo que permite:

• Guardar electrónicos a archivos en text formato en lugar de enviarlos
• Guardar electrónicos a archivos en mbox formato en lugar de enviarlos
• agregar información de registro en lugar de enviar correo electrónico