Context Hierarchy

DispatcherServlet은 자체적인 설정을 위해 WebApplicationContext(ApplicationContext의 확장 버전)를 필요로 합니다.
WebApplicationContext는 ServletContext 및 이를 사용하는 Servlet과 연결됩니다. 또한 ServletContext에 바인딩되므로, 애플리케이션에서 RequestContextUtils의 정적 메서드를 사용하여 WebApplicationContext를 찾을 수 있습니다.

컨텍스트 계층 구조의 개념

대부분의 애플리케이션에서는 단일 WebApplicationContext를 사용하는 것이 간단하며 충분합니다.
그러나 더 복잡한 애플리케이션에서는 컨텍스트 계층 구조(Context Hierarchy)를 구성할 수도 있습니다.

 

➡ 컨텍스트 계층 구조란?

• 하나의 루트 WebApplicationContext가 여러 개의 DispatcherServlet(또는 기타 Servlet) 인스턴스와 공유될 수 있습니다.
• 각 DispatcherServlet은 자체적인 자식 WebApplicationContext를 가질 수 있습니다.
• 자세한 내용은 ApplicationContext의 추가 기능(Additional Capabilities of the ApplicationContext)에서 확인할 수 있습니다.

Root WebApplicationContext와 자식 WebApplicationContext

📌 Root WebApplicationContext

• 여러 서블릿 인스턴스에서 공유됩니다.
• 일반적으로 데이터 리포지토리(Data Repository), 비즈니스 서비스(Business Service) 같은 인프라 관련 빈을 포함합니다.
• 서블릿별 WebApplicationContext가 해당 빈을 상속받을 수 있습니다.

📌 서블릿별 WebApplicationContext (자식 컨텍스트)

• 특정 서블릿(예: DispatcherServlet)에 국한된 빈을 포함합니다.
• 루트 컨텍스트의 빈을 재정의(Override, 즉 다시 선언)할 수도 있습니다.
• 보통 컨트롤러(Controller), 뷰 리졸버(ViewResolver), 핸들러 매핑(HandlerMapping) 같은 웹 관련 빈을 포함합니다.

📌 아래 그림에서 이 개념을 시각적으로 확인할 수 있습니다.

• 루트 WebApplicationContext는 서비스(Service)와 리포지토리(Repository)를 포함합니다.
• 각 DispatcherServlet의 WebApplicationContext는 컨트롤러, 뷰 리졸버, 핸들러 매핑을 포함합니다.

 

다음 예제는 WebApplicationContext 계층 구조를 구성합니다:

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/*" };
    }
}

애플리케이션 컨텍스트 계층 구조가 필요하지 않은 경우, 모든 설정을 getRootConfigClasses() 메서드를 통해 리턴하고, getServletConfigClasses() 메서드에서는 null을 반환할 수 있습니다.

다음 예는 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 서블릿 파라미터를 비워둘 수 있습니다.

🚀 Summary

• DispatcherServlet은 자체 WebApplicationContext를 필요로 하며, ServletContext와 연결됩니다.
• 대부분의 애플리케이션에서는 하나의 WebApplicationContext만 있어도 충분합니다.
• 컨텍스트 계층 구조를 사용하면 루트 컨텍스트(비즈니스 로직, 데이터 계층)와 서블릿별 컨텍스트(컨트롤러, 뷰 등)를 분리할 수 있습니다.
• 루트 컨텍스트의 빈은 서블릿 컨텍스트에서 상속받을 수 있으며, 필요하면 다시 선언(재정의)할 수도 있습니다.

➡ 즉, Spring MVC에서는 컨텍스트 계층 구조를 활용하여 애플리케이션을 유연하고 확장성 있게 설계할 수 있습니다.

 

출처 : https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-servlet/context-hierarchy.html