Portfolio

시작전 간단 정리

Servlet Container를 통해 client의 요청을 받는다.

요청은 다시 Dispatcher Servlet으로 보내 진다.

Dispatcher Servlet은 Front-Controller의 역할을 하고 요청에 맞는 핸들러(컨트롤러)를 찾아 보낸다.

컨트롤러는 비즈니스 로직을 수행 한 후 응답을 반환한다.

여기서 알아 볼 것은...

Dispatcher Servlet에 대해서 스프링 공식 문서를 보며 알아보려 합니다.

https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#spring-web

DispatcherServlet이란?

Spring MVC, as many other web frameworks, is designed around the front controller pattern where a central Servlet, the DispatcherServlet, provides a shared algorithm for request processing, while actual work is performed by configurable delegate components. This model is flexible and supports diverse workflows.

💡

Spring MVC과 다른 웹 프레임워크들은 front-controller pattern을 중심으로 설계되어 있다고 한다.

💡

특히 중심 역할을 하는 DispatcherServlet이 여러 리퀘스트들을 핸들링합니다.

The DispatcherServlet, as any Servlet, needs to be declared and mapped according to the Servlet specification by using Java configuration or in web.xml. In turn, the DispatcherServlet uses Spring configuration to discover the delegate components it needs for request mapping, view resolution, exception handling, etc...

💡

DispatcherServlet도 다른 Servlet 처럼 설정 클래스나 xml로 매핑 해 줄 필요가 있다 합니다.

Dispatcher Servlet 코드 예시

💡

아래는 스프링 설정을 등록하고 DispatcherServlet 를 등록하는 코드입니다.


public class MyWebApplicationInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext servletContext) {

        // Load Spring web application configuration
        AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();
        context.register(AppConfig.class);

        // Create and register the DispatcherServlet
        DispatcherServlet servlet = new DispatcherServlet(context);
        ServletRegistration.Dynamic registration = servletContext.addServlet("app", servlet);
        registration.setLoadOnStartup(1);
				// addMapping을 통해 /app/**로 오는 요청들을 처리하게끔 합니다.
        registration.addMapping("/app/*");
    }
}

DispatcherServlet expects a WebApplicationContext (an extension of a plain ApplicationContext) for its own configuration. WebApplicationContext has a link to the ServletContext and the Servlet with which it is associated. It is also bound to the ServletContext such that applications can use static methods on RequestContextUtils to look up the WebApplicationContext if they need access to it.

💡

DispatcherServlet 은 WebApplicationContext 아니면 ApplicationContext 을 상속받은 설정 클래스를 줘야 합니다. ( 위 코드 참조 )

💡

WebApplicationContext 은 ServletContext 과 연관이 있습니다. ( 아래 코드 참조 )

💡

그리고 ServletContext 내부에는 연관된 Servlet 를 찾습니다. ( 아래 코드 참조 )


public interface WebApplicationContext extends ApplicationContext {
	...
	
	/**
	 * Return the standard Servlet API ServletContext for this application.
	 */
	@Nullable
	ServletContext getServletContext();

}


public interface ServletContext {
	...

	public ServletRegistration getServletRegistration(String servletName);
}

Context Hierarchy

Processing

The WebApplicationContext is searched for and bound in the request as an attribute that the controller and other elements in the process can use. It is bound by default under the DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE key.

The locale resolver is bound to the request to let elements in the process resolve the locale to use when processing the request (rendering the view, preparing data, and so on). If you do not need locale resolving, you do not need the locale resolver.

The theme resolver is bound to the request to let elements such as views determine which theme to use. If you do not use themes, you can ignore it.

If you specify a multipart file resolver, the request is inspected for multiparts. If multiparts are found, the request is wrapped in a MultipartHttpServletRequest for further processing by other elements in the process. See Multipart Resolver for further information about multipart handling.

An appropriate handler is searched for. If a handler is found, the execution chain associated with the handler (preprocessors, postprocessors, and controllers) is run to prepare a model for rendering. Alternatively, for annotated controllers, the response can be rendered (within the HandlerAdapter) instead of returning a view.

If a model is returned, the view is rendered. If no model is returned (maybe due to a preprocessor or postprocessor intercepting the request, perhaps for security reasons), no view is rendered, because the request could already have been fulfilled.

창호😁