The applicationContext.xml file is the brain of the Spring framework. It holds the configuration of all beans (classes) that the application uses and the Spring container manages. They are wired up through Spring’s use of the Dependency Injection Pattern. It can hold the wiring for things like datasources, DAOs, the SessionFactory, classes required for transaction handling and heaps more. I will not go into these - have a look at Spring’s Reference Documentation for more details.

Instantiating the context in a web application:

The easiest way to do this is by creating it as part of application start-up - as a ServletContextListener:

import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import org.springframework.context.ApplicationContext;
import org.springframework.web.context.ContextLoaderListener;
import org.springframework.web.context.support.WebApplicationContextUtils;
 
/**
* Get the application context when it is available and set it in the SpringWrapper.
*/
public class ServletContextListener extends ContextLoaderListener
{
	public void contextInitialized(ServletContextEvent event)
	{
		super.contextInitialized(event);
		ServletContext servletContext = event.getServletContext();
		ApplicationContext appContext =
		WebApplicationContextUtils.getRequiredWebApplicationContext(servletContext);
		SpringWrapper.setApplicationContext(appContext);
	}
}

All that is then required is to add the listener in the web.xml:

<listener>
	<listener-class>com.company.util.ServletContextListener</listener-class>
</listener>

Now, when the application starts the Spring context is loaded up and set in a static variable inside the SpringWrapper class. (See here for full code of this class - it includes convenience methods for unsetting and overloading the default context with another one to be used when unit testing)

Instantiating some beans is now as simple as:

SpringWrapper.getApplicationContext().getBean("someBeanName");

Instantiating an alternative applicationContext during unit testing:

When unit testing it is often useful to have an alternative context load up your Spring dependencies. For example for overwriting the default datasource bean that is setup from the JndiObjectFactoryBean (which is the preferred way for web apps) with one that sets up a datasource directly from a DriverManagerDataSource so that you can access the db from your unit or integration tests. Another reason why you may want to have a separate test-applicationContext is to stub out certain beans or replace them with mock objects for the purposes of isolating the bean being tested. Whatever the need, this is easy to do by instantiating the context using the FileSystemXmlApplicationContext(String[] locations) constructor. The locations are read one by one and the xml files found in those read in one by one - configurations from the latter extending any previous ones.

The implementation of this can be seen here SpringWrapper.java.

I find that it is not unusual to have several test-applicationContext.xml files each stubbing out different beans and/or parameters to properly isolate classes for unit testing.

So I finally decided to migrate from my wiki (still available here) to a blog. Actually Aggie helped me set it up since she has quite a bit of experience running wordpress having had her own blog for some time now. I have no idea what to call it and am not sure about the theme yet but at least it’s up and running!