CODEWITHSUNDEEP
javaspringtestingspring-mvc
mibutec
mibutec

Reputation: 2997

Spring MVC with several configurations

for my spring-mvc application I created several types of configuration (unittest, integration, qa, production). All the configs are in one war-file, so there is only one type of application I create. Which configuration to take should be decided by the server, where the application is running.

To decide what kind of configuration should be used, I have to look into a file. After that I can decide which configuration should be used by spring mvc.

For now by convention there is always the -servlet.xml used. Is there a way how to decide dynamically which config to take?

Regards, Michael

Upvotes: 1

Views: 1316

Answers (3)

mibutec
mibutec

Reputation: 2997

After all I'm using PropertyPlaceholderConfigurer but slightly differnt than Axel mentioned: I load just one property from my configuration and use it to determine which import to use. Because of https://jira.springframework.org/browse/SPR-1332 I cant use a file to store the instance-type, but have to use environment-variables.

<bean id="propertyConfigurerOne" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>
<import resource="classpath:/web${vabse.Environment}.xml"/>

Upvotes: 0

hisdrewness
hisdrewness

Reputation: 7651

I have the same setup, but I use maven to build the WARs differently. I use a PropertyPlaceholderConfigurer in the context:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:p="http://www.springframework.org/schema/p"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

   <context:property-placeholder location="classpath:datasource.properties" ignore-unresolvable="true" />

   <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"
      p:driverClassName="${jdbc.driver}"
      p:url="${jdbc.url}"
      p:username="${jdbc.username}"
      p:password="${jdbc.password}" />

   <!--other beans-->
</beans>

then I setup an environments folder:

src
--main
----environments
------dev
--------datasource.properties
------cert
--------datasource.properties
------prod
--------datasource.properties

Then in my Maven pom, I use a build profile to copy anything in the environment folder based on a parameter flag in the maven command:

<profiles>
        <profile>
            <id>environment</id>
            <activation>
                <property>
                    <name>environment</name>
                </property>
            </activation>
            <build>
                <resources>
                    <resource>
                        <directory>
                            src/main/environments/${environment}
                        </directory>
                    </resource>
                </resources>
                <!-- other build config and plugins -->

so the following command:

mvn clean -Denvironment=dev install

would copy the dev datasource.properties to the war

Upvotes: 0

Axel Fontaine
Axel Fontaine

Reputation: 35169

Here is a solution that I use. It works very well:

  • Put the configuration differences in property files.
  • Keep a single Spring xml with placeholders.
  • Use PropertyPlaceholderConfigurer to set the properties.
  • PropertyPlaceholderConfigurer can use system properties to resolve the name of the property file to load.
  • Set a system property with the name of your environment before initilizing the PropertyPlaceholderConfigurer (you can do this in a bean that reads the value out of your file).

And there you go! The environment will be cleanly detected, and the relevant properties will be loaded!

No need to wait for Spring 3.1, you can use this solution today with 3.0.

Upvotes: 4

Related Questions