Common strategies when defining Spring beans for different environments

Question

What are common strategies for defining a bunch of beans, which are used differently in development and production environments?

Let\'s say I have 2 beans, each impl

Answer 1

Here goes what Spring reference documentation says about PropertyPlaceholderConfigurer

The PropertyPlaceholderConfigurer does not look for properties only in the Properties file you specify, but also checks against the Java System properties if it cannot find a property you are trying to use.

As you can see above you can set up a Java System property

On The development machine

-Dprofile=development

On The production machine

-Dprofile=production

So you can define a global application context settings which import each layered context settings as follows

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

Keep in mind all location paths are relative to the definition file doing the importing

Therefore, This kind of configuration is supported by Spring

It is generally preferable to keep an indirection for such absolute locations, for example, through "${...}" placeholders That are resolved against JVM system properties at runtime.

Answer 2

This functionality is on SpringSource's radar, and is slated for future releases.

See here and here.

Answer 3

This is what I have been using in many of my projects. Have all your environment independent beans in say common.xml and all others in say dev.xml/qa.xml/prod.xml. If you are using ant to build your project,then supply the environment as an argument to the build process and let the build script include appropriate env.xml and omit others. I mean,the build script will copy dev.xml as env.xml if its a dev environment or qa.xml as env.xml if its QA. So the code which loads the bean definitions will always use "common.xml,env.xml".