The very basic question that comes to mind when we start up with Spring Framework, is what role does ApplicationContext has to play in Spring, how is it different from WebApplicationContext, and before all that, what actually is a context in Java?
1. What is a context in Java?
A context can be said as the running environment that is provided to the current unit of work. It may be the environment variables, instance variables, state of the classes, and so on. When I say this, I mean that ServletContext represents the servlet’s environment within its container, similar to ApplicationContext, which represents the Spring application’s core environment within the Spring container.
So similarly there are Servlet’s ServletContext, JSF’s FacesContext, Spring’s ApplicationContext, Android’s Context, JNDI’s InitialContext, and all these contexts follow the Facade Pattern to abstract the environment specific details to the end user, providing the interface methods to interact with.
2. Spring Context Configuration
In Spring web applications, there are two contexts that gets initialized at server startup, each of which is configured and initialized differently. One is the “Application Context” and the other is the “Web Application Context“.
Application Context is the context initialized by a ContextLoaderListener or ContextLoaderServlet that we define in our application’s web.xml file and the configuration would look something like this:
In the above configuration, we are asking Spring to load root-context.xml and create an Application Context from it. If contextConfigLocation is not mentioned as in the below snippet, it will by default look for /WEB-INF/applicationContext.xml.
WebApplicationContext is the another servlet-specific context that is loaded based on the dispatcher servlets configured in the application’s web.xml file. So each dispatcher servlet has its own servlet-context initialized from <servlet-name>-servlet.xml file. This allows us to categorize the incoming requests based on the servlet’s url-pattern and handle them accordingly, such that one of dispatcher servlets could help serving the web pages via Controller, while another one could be used to implement a stateless REST web service. So with that, we understand that a single web application can have multiple dispatcher-servlet configurations, thereby having multiple web-application contexts.
If we want to change the name of the dispatcher-servlet file name or change it’s location, we can add init-param with contextConfigLocation as param-name, as can be seen below –
So with dispatcher-servlet init-param specified as in the above web.xml code snippet, Spring no more finds the dispatcher-servlet context file with the name mvc-dispatcher-servlet.xml, but instead looks for the one specified as the init-param value for contextConfigLocation, i.e. sample-dispatcher-servlet.xml.
2.3 Difference between the two contexts
So the best part of this article, is what’s the difference between the two contexts?
Firstly, as already mentioned, ApplicationContext is the root-context, that has bean configurations we might want to use (and re-use) across the entire application as singletons. There is always a single application context in a web application. Whereas, there can be multiple WebApplicationContexts for each of the dispatcher servlets we specify in our application’s web.xml.
It’s always better to keep a clear separation between middle-tier services such as business logic components and data access classes (which we prefer defining in the ApplicationContext XML), and web-related components such as controllers and view-resolvers (which we prefer defining in the respective dispatcher-servlet‘s WebApplicationContext).