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>
        <server-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>
        <server-name>app1</servlet-name>
        <url-pattern>/app1/*</url-pattern>
    </servlet-mapping>
</web-app>
Якщо в ієрархії контекстів програми немає потреби, програми можуть конфігурувати лише "кореневий" контекст і залишати параметр сервлета contextConfigLocation порожнім.