Change Spring email settings based on dev/test/prod mode

Question

I often test my application with a copy of a live database, but have to be careful to not do any actions that cause an email to be sent to a user. I'd love to have a way to configure spring so that when I'm in dev or test mode, that no email will get sent to real users. Ideally, I'd like for all of the emails that should have gone to the user to go instead to a mailbox that I can examine. And I don't want to change any code to make this happen, just xml config files.

I'm already using PropertyPlaceholderConfigurer and am reading in different property files based on if I'm running in production, test, or dev modes. I configure a JavaMailSenderImpl based on values in the property file. I'm also using a SimpleMailMessage to create a template with the From address.

Ideally there would be a way to rewrite to TO address of all outgoing emails to a test account if I'm running in dev or test mode.

My first thought was to use a different SMTP server for dev and test. But then I'd have to also manage another mail server, and would need to customize it so that it wouldn't send mail to anywhere, but would instead deliver it to a single mailbox. I don't want to add more management requirements if possible.

Maybe that's the best solution, but it seems like there should be a way to intercept the emails and change the recipient.

Has anyone dealt with this problem before? What solutions did you come up with?

Answer 1

Note: my answer is predicated on using Maven, so this is more about building than anything, but using spring lets me conveniently inject the values.

I use a property-placeholder in and construct beans like:

jdbc.properties:

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

applicationContext.xml (using context namespace)

<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>

Then I store the environments in separate folders with domain specific values like:

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

Using maven profiles (from pom.xml):

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

You can run any maven command with the -Denviroment property to flex the properties:

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

etc. and any files from that environment folder are copied into the target or artifact along with any src/main/resources files.

Answer 2

I've had a similar requirement in the past, and my solution was to write what I called EnvironmentSelectingFactoryBean (Spring does seem to encourage long class names...). This was a FactoryBean implementation that would "select" one of a range of available beans based on the current application envrironment.

If I show you some example XML, I think you'll get the 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>

So, EnvironmentSelectingFactoryBean knows whether you're running in "test" or "production" mode, picks the appropriate bean from the beanMap, and spits that our from its FactoryBean.getObject() method. Both beans in the beanMap are real mail senders, not stubs, each with different proprty placeholder values, but you never run the risk of getting the wrong one.

Client code will just see a single JavaMailSender bean.

Answer 3

I see that you state a specific requirement that you don't want to change any code. I still would like to suggest creating a stub implementation of JavaMailSender. That way, you could inject the stub object in your dev and test builds.