The next logical idea is to try to move this host configuration to the web.xml file (if possible), since it is usually modified less often than applicationContext.xml. Luckily, there is a solution available for us to use. Take a look at the following example of the web.xml configuration snippet:

As you can see, beside the usual ContextLoaderListener that is usually found in the web.xml file, we put the contextConfigLocation context parameter configuration. This parameter is used to instruct the framework where to look for these configuration files. If it is omitted, Spring will look only in the applicationContext.xml, but here we defined our host-specific configuration file to be used as well.

With this approach we moved all host-specific configuration from the applicationContext.xml file and thus eased its synchronization among various application deployments.

If this approach becomes your new habit, there is one more thing you can do to make it more flexible. By following the instructions that follow, you can remove host-specific configuration even from the web.xml file.

In order to do that, we need to create our specific application context class:

This class extends Spring's XmlWebApplicationContext, which is used by default. The XmlWebApplicationContext class takes the configuration for the web application from XML definition files. By default, it configures the application from applicationContext.xml and [servlet-name]-servlet.xml files. The only additional task that our class performs is getting the name of the host on which it is executed and adding the applicationContext-[hostname].xml file to the list of configuration files.

In order to use this class, we need to compile it, include it in the classpath, and instruct Spring framework to use it. The first two steps are well-known and we will not describe them here. We can instruct Spring to use it through the contextClass context parameter. Instead of the previous configuration in the web.xml file, we can put something like this:

If this configuration snippet is used, our class will be used and three files will be used to initialize the framework: [servlet-name]-servlet.xml, applicationContext-[hostname].xml, and applicationContext.xml.

As you can see, the applicationContext.xml and web.xml files are now completely free of any specific configuration details and there is no fear that you will break your configuration during the application update.

However, there is one drawback to this approach. It is reflected in the need to have this third configuration file on the application deployment, whether you will use it or not. In the case that there is no specific host configuration needed, it could look like this:

Finally, you need to know what specific hostname our application context class will look for. The easiest way to check your host's name is to execute the following code on the machine:

System.out.println(InetAddress.getLocalHost().getHostName())

You can execute this as Java code or as a script in your favorite scripting language with a Java-like syntax, such as BeanShell or Groovy. When you have the name of the host, you should create a default empty /WEB-INF/applicationContext-[hostname].xml file (like the one we have defined above) and you'll be ready to go.

Conclusion

In this article, I've presented some configuration tips that could ease your day-to-day work with the Spring MVC framework. If you ever find yourself trying to figure out how to maintain various web application deployments, try to find the most suitable solution for your development process. It will make your life much easier.

Resources

Dejan Bosanac
is a software developer, technology consultant and author. He is focused on the integration and interoperability of different technologies, especially the ones related to Java and the Web.