DispatcherServlet ожидает WebApplicationContext (расширение обычного ApplicationContext) для своей собственной конфигурации. WebApplicationContext имеет ссылку на ServletContext и Servlet, с которым он связан. Он также привязан к ServletContext, поэтому приложения могут использовать статические методы RequestContextUtils для поиска WebApplicationContext, если им требуется доступ к нему.

Для многих приложений достаточно иметь один WebApplicationContext. Также возможна иерархия контекстов, в которой один корневой WebApplicationContext используется совместно несколькими экземплярами DispatcherServlet (или других Servlet), каждый из которых имеет свою собственную конфигурацию дочернего WebApplicationContext.

Корневой WebApplicationContext обычно содержит инфраструктурные бины, такие как хранилища данных и бизнес-сервисы, которые должны быть общими для нескольких экземпляров Servlet. Эти бины эффективно наследуются и могут быть переопределены (то есть повторно объявлены) в дочернем WebApplicationContext, специфичном для сервлета, который обычно содержит локальные для данного Servlet бины. На следующем изображении показана эта взаимосвязь:

В следующем примере конфигурируется иерархия WebApplicationContext:

Java
public class MyWebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
    @Override
    protected Class<?>[] getRootConfigClasses() {
        return new Class<?>[] { RootConfig.class };
    }
    @Override
    protected Class<?>[] getServletConfigClasses() {
        return new Class<?>[] { App1Config.class };
    }
    @Override
    protected String[] getServletMappings() {
        return new String[] { "/app1/*" };
    }
}
Kotlin
class MyWebAppInitializer : AbstractAnnotationConfigDispatcherServletInitializer() {
    override fun getRootConfigClasses(): Array<Class<*>> {
        return arrayOf(RootConfig::class.java)
    }
    override fun getServletConfigClasses(): Array<Class<*>> {
        return arrayOf(App1Config::class.java)
    }
    override fun getServletMappings(): Array<String> {
        return arrayOf("/app1/*")
    }
}
Если в иерархии контекстов приложения нет нужды, приложения могут возвращать всю конфигурацию через getRootConfigClasses() и null из getServletConfigClasses().

В следующем примере показан эквивалент web.xml:

<web-app>
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/root-context.xml</param-value>
    </context-param>
    <servlet>
        <servlet-name>app1</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/app1-context.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>app1</servlet-name>
        <url-pattern>/app1/*</url-pattern>
    </servlet-mapping>
</web-app>
Если в иерархии контекстов приложения нет нужды, приложения могут конфигурировать лишь "корневой" контекст и оставлять параметр сервлета contextConfigLocation пустым.