Solución:
Contexto de aplicación web extendido Contexto de aplicación que está diseñado para funcionar con el estándar javax.servlet.ServletContext para que pueda comunicarse con el contenedor.
public interface WebApplicationContext extends ApplicationContext {
ServletContext getServletContext();
}
Los beans, instanciados en WebApplicationContext también podrán usar ServletContext si implementan la interfaz ServletContextAware
package org.springframework.web.context;
public interface ServletContextAware extends Aware {
void setServletContext(ServletContext servletContext);
}
Hay muchas cosas que se pueden hacer con la instancia de ServletContext, por ejemplo, acceder a los recursos WEB-INF (configuraciones xml, etc.) llamando al método getResourceAsStream (). Normalmente, todos los contextos de aplicación definidos en web.xml en una aplicación Spring de servlet son contextos de aplicación web, esto va tanto al contexto de la aplicación web raíz como al contexto de la aplicación del servlet.
Además, dependiendo de las capacidades del contexto de la aplicación web, puede hacer que su aplicación sea un poco más difícil de probar, y es posible que deba usar la clase MockServletContext para probar.
Diferencia entre servlet y contexto raíz
Spring le permite construir jerarquías de contexto de aplicaciones multinivel, por lo que el bean requerido se obtendrá del contexto principal si no está presente en el contexto de la aplicación actual. En las aplicaciones web, de forma predeterminada, hay dos niveles de jerarquía, contextos raíz y servlet: 
Esto le permite ejecutar algunos servicios como singletons para toda la aplicación (los beans Spring Security y los servicios básicos de acceso a la base de datos normalmente residen aquí) y otros como servicios separados en los servlets correspondientes para evitar conflictos de nombres entre beans. Por ejemplo, un contexto de servlet servirá las páginas web y otro implementará un servicio web sin estado.
Esta separación de dos niveles sale de la caja cuando usa las clases de servlet de primavera: para configurar el contexto de la aplicación raíz debe usar parámetro de contexto etiqueta en su web.xml
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/root-context.xml
/WEB-INF/applicationContext-security.xml
</param-value>
</context-param>
(el contexto de la aplicación raíz lo crea ContextLoaderListener, que se declara en web.xml
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
) y servlet etiqueta para los contextos de la aplicación de servlet
<servlet>
<servlet-name>myservlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>app-servlet.xml</param-value>
</init-param>
</servlet>
Tenga en cuenta que si se omite init-param, Spring usará myservlet-servlet.xml en este ejemplo.
Ver también: Diferencia entre applicationContext.xml y spring-servlet.xml en Spring Framework
La respuesta aceptada es a través, pero hay una explicación oficial sobre esto:
WebApplicationContext es una extensión del ApplicationContext simple que tiene algunas características adicionales necesarias para las aplicaciones web. Se diferencia de un ApplicationContext normal en que es capaz de resolver temas (consulte Uso de temas) y en que sabe con qué Servlet está asociado (al tener un enlace al ServletContext). El WebApplicationContext está vinculado al ServletContext y, al usar métodos estáticos en la clase RequestContextUtils, siempre puede buscar el WebApplicationContext si necesita acceder a él.
Citado de la referencia del marco web de Spring
Por cierto, el servlet y el contexto raíz son ambos webApplicationContext:
Volviendo a los días de Servlet, web.xml solo puede tener una <context-param>, por lo que solo se crea un objeto de contexto cuando el servidor carga una aplicación y los datos en ese contexto se comparten entre todos los recursos (por ejemplo: Servlets y JSP). Es lo mismo que tener el nombre del controlador de la base de datos en el contexto, que no cambiará. De manera similar, cuando declaramos el parámetro contextConfigLocation en <contex-param> Spring crea un objeto de contexto de aplicación.
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>com.myApp.ApplicationContext</param-value>
</context-param>
Puede tener varios Servlets en una aplicación. Por ejemplo, es posible que desee manejar las solicitudes / secure / * de una manera y / non-seucre / * de otra manera. Para cada uno de estos servlets, puede tener un objeto de contexto, que es un WebApplicationContext.
<servlet>
<servlet-name>SecureSpringDispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextClass</param-name>
<param-value>com.myapp.secure.SecureContext</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>SecureSpringDispatcher</servlet-name>
<url-pattern>/secure/*</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>NonSecureSpringDispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextClass</param-name>
<param-value>com.myapp.non-secure.NonSecureContext</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>NonSecureSpringDispatcher</servlet-name>
<url-pattern>/non-secure/*</url-patten>
</servlet-mapping>