ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Advanced Configuration of the Spring MVC Framework
Pages: 1, 2, 3

Solutions

Synchronizing Bean Properties

One possible solution to this issue is to put all host-specific parameters in a regular Java properties file and use Spring's PropertyPlaceHolderConfigurer class to map these parameters to your bean properties.



Using this solution, we will have a properties file (/WEB-INF/jdbc.properties) that looks like this:

jdbc.driver=org.postgresql.Driver
jdbc.url=jdbc:postgresql://localhost/test
jdbc.user=postgres
jdbc.password=

and our bean configuration will look like this:


<bean id="propertyConfigurer" 
 class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="location">
       <value>/WEB-INF/jdbc.properties</value>
    </property>
</bean>

<bean id="dataSource" 
 class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName">
         <value>${jdbc.driver}</value>
    </property>
    <property name="url">
         <value>${jdbc.url}</value>
    </property>
    <property name="username">
         <value>${jdbc.user}</value>
    </property>
    <property name="password">
         <value>${jdbc.password}</value>
    </property>
</bean>

As you can see, we defined an instance of the PropertyPlaceholderConfigurer class and set its location property to our properties files. This class is implemented as a bean factory post-processor and it will replace all placeholders (${...} values) with the properties defined in the file.

With this technique, we can remove all host-specific configuration properties from the applicationContext.xml file. In that way, we can freely add new beans to that file without worrying about synchronization of host-specific properties, which can simplify product deployment and maintenance.

Synchronizing Wirings

The above technique solved the first problem, but still it is not suitable if you plan to modify bean wirings among application deployments. One solution to this problem could be to create one more XML definition file named applicationContext-[hostname].xml, where [hostname] is actually the name of the host on which you will deploy your application. For example, on your local machine, this file would be usually called applicationContext-localhost.xml, where in deployment it could be something like applicationContext-somehost.com.xml.

As you can guess, this file should contain all configuration beans that are specific to a certain host. In this article, we will assume that our definition of the dataSource bean will be located in this kind of file instead of the general-purpose applicationContext.xml definition. Of course, this mechanism in not incompatible with the previous one, but for simplicity reasons we will now focus entirely on this method.

Now that we have our specific configuration, we should discuss how we can integrate it into the overall Spring MVC configuration concept. There are number of ways to achieve this, and we are going to discuss all of them in detail soon. But first, it is important to note that because some beans will be now located in the separate configuration file, all local references to them (in applicationContext.xml) must be converted to the global one.

For example, references like this one:

 <property name="someProperty">
   <ref local="someBean"/>
 </property>

should be changed to the following:

 <property name="someProperty">
   <ref bean="someBean"/>
 </property>

When this is done, there are numerous ways in which we can add an additional resource for configuration purposes. The first and most obvious is to use the <import> tag to include this additional resource in the applicationContext.xml configuration file. You usually put this tag at the beginning of the applicationContext.xml file. The example could look something like this:

<import resource="applicationContext-somehost.com.xml"/>

Now we have all host-specific wirings in the separate XML definition file and all general-purpose bean definitions in the regular application context definition file. Because the most of the beans are not host-specific, we are free to handle the applicationContext.xml file just as any other resource in our web application and synchronize it through the appropriate version control system.

But the aforementioned approach also has its drawbacks. If you want to keep your different configurations in different XML files, you will still have to worry about applicationContext.xml synchronization, since the name of the resource must be changed for every server. It is much better than the original solution, since now there is only the file name that should be taken care of, but it still requires manual assistance from the developer.

Pages: 1, 2, 3

Next Pagearrow