Static Web Page

웹 서버에서 정적 웹 페이지의 렌더링을 하고 반환하는 기술

CGI(Common Gateway Interface)

웹 서버의 동적 컨텐츠 처리를 위한 기술

동작 구조

1. 요청
2. 웹 서버 수신 및 대응되는 CGI 프로그램 확인
3. 운영체제에 의해 CGI 프로그램 실행(동적 처리)
4. 렌더링된 HTML 반환

단점

• 요청마다 CGI 프로세스가 실행됨
• 스크립트 언어 CGI 프로그램의 경우 매번 스크립트를 해석해야 됨
• C, Perl, Shell Script로 개발했는데, 이 언어들은 대규모 웹 서버 설계에 적합하지 않음

웹 서버에서 임의의 프로그램을 실행할 수 있기 때문에 간혹 쓰이는 경우도 있음

Server Side Scripting

웹 서버 자체에서 동적 페이지를 처리하는 기술

요청마다 프로세스를 생성하여 운영체제를 통해 실행하지 않고 웹 서버 내의 스레드를 통해 직접 처리

자바같은 객체지향 언어으로 대규모 웹 서버를 개발

Servlet

• Java EE 사양의 일부로 HTTP를 처리하고 응답을 생성하는 서버 컴포넌트
  • HTML 페이지 생성, 세션 관리, DB 처리 등
  • 자바로 작성되며 JVM 위에서 실행
• ServletContainer가 Servlet의 생명주기와 실행을 관리함
• 멀티 스레드 모델 : 서블릿 인스턴스 하나(스레드)와 여러 클라이언트 요청마다 별도의 스레드를 할당하여 요청 처리
• DispatchType : 서블릿 요청이 처리되는 방식
  • REQUEST : 기본 디스패치 타입
  • FORWARD : 다른 Servlet이나 JSP로 요청을 전달할 때 사용(RequestDispatcher.forward())
  • INCLUDE : 다른 Servlet이나 JSP를 응답에 포함시킬 때 사용(RequestDispather.include())
  • ERROR : 에러가 발생했을 때(/error)
  • ASYNC : 비동기 처리(Servlet 3.0 이상)

JSP

• JSP는 HTML 페이지에 자바 코드를 삽입하는 방식, Servlet은 자바 클래스에 HTML을 삽입하는 방식
• 자바에서 HTML 관련 코드를 Servlet보다 편리하게 작성할 수 있는 Server Side Scripting 기술
• Servlet을 기반으로 하며 JSP 페이지는 Servlet으로 변환되어 실행됨
• MVC 아키텍처를 지원함
• JSP - View, Servlet - Controller

MVC

두 가지의 관심사(비즈니스 로직, 화면)를 분리하는 디자인패턴

구성 요소

• Model : 데이터와 비즈니스 로직 처리
• View : 화면 처리
• Controller : 요청 수신/검증 및 Model과 View에게 명령 전달

동작 구조

1. 컨트롤러 요청 수신
2. 컨트롤러 -> 모델 데이터 변경
3. 컨트롤러 -> 뷰 화면 처리

SSR(서버 사이드 렌더링) : 서버에서 화면 처리 담당

CSR(클라이언트 사이드 렌더링) : 클라이언트에서 화면 처리 담당

Spring MVC, FrontController

MVC 패턴의 Controller(Servlet)는 path(요청 url)에 마다 개별 Controller(Servlet)를 만듦

-> Controller가 수행하는 검증, 세션 관리, 필터 등의 코드가 중복됨

FrontController는 모든 요청을 처리하는 Controller를 두는 디자인패턴으로 코드 중복없이 재사용할 수 있는 유연한 구조를 가짐

스프링 MVC 구성요소

• DispatcherServlet
  • FrontController 역할
  • 요청에 맞는 Component 검색 및 실행
  • View 해결
  • 에러 처리 등
• Handler Mapping
  • 요청(URL)을 어느 Controller의 메서드가 처리할 지 결정
  • RequestMappingHandlerMapping : @RequestMapping 기반 어노테이션이 적용된 컨트롤러 메서드 매핑
• Controller(Handler)
  • 요청을 처리하는 컴포넌트
  • URL 별로 로직을 수행할 메서드를 가짐
• View Resolver
  • Controller가 반환하는 View 이름을 기반으로 실제 View를 찾는 역할
  • View 파일을 렌더링하여 클라이언트에게 응답
  • InteralResourceViewResolver : View 이름을 기반으로 내부 리소스를 찾는 View Resolver
• View
  • View 파일

스프링 MVC 계층 구조

• Presentation Layer
  • 요청을 처리하는 계층
  • Controller, View
• Business Logic Layer
  • 애플리케이션 핵심 로직을 수행하는 계층
  • Service : 비즈니스 로직 집합
  • Domain Model : 비즈니스 로직/연산, 데이터
• Data Access Layer
  • DB 접근, 영속성 기술 수행 계층
  • DAO(Data Access Object) :
  • Repository :

DispatcherServlet과 WebApplicationContext 관계

1. 각 DispatcherServlet은 자신만의 Servlet WebApplicationContext가 존재
2. 또한 애플리케이션 로딩 시점에 생성되는 Root WebApplicationContext를 부모로 설정

Root WebApplicationContext

• 애플리케이션의 공통 컴포넌트(서비스 계층, 데이터 액세스 계층)
• ContextLoaderListnener에 의해 초기화
  • 스프링 - web.xml, application-context.xml
  • 스프링부트 - @SpringBootApplication

Servlet WebApplicationContext

• 프레젠테이션 계층(Controller, View Resolver, Handler Mapping)
• DispatcherServlet 초기화 시 자동 생성
  • 스프링 - dispatcher-servlet.xml
  • 스프링부트 - @EnableAutoConfiguration을 통해 내부적으로 DispatcherServlet 초기화 및 Servlet WebApplicationContext 자동 처리
• Servlet WebApplicationContext 빈은 특정 Servlet에서만 접근할 수 있음

Filter

Servlet과 마찬가지로 Java/Jakarata EE 스펙에 포함됨

특징

• HTTP Request 사전 처리, 사후 처리를 담당하는 요소(Servlet 실행 전/후 동작)
• url(path)에 매핑되는 Filter 동작
• 다음 Filter의 실행을 중단하거나 실행 결과를 무시하고 직접 응답을 반환할 수 있음
• ServletContainer 내에서 동작

FilterChain

• FilterChain은 여러 Filter가 순서대로 연결된 체인 형태로 작동
• Servlet은 모든 FilterChain의 Filter가 실행된 이후 마지막에 호출됨

Interceptor

Spring MVC 스펙에 포함됨

특징

• DispatcherServlet에서 Controller(Handler)로 요청 위임 전/후/완료 후에 동작하는 요소
• url(path)에 매핑되는 Interceptor 동작
• 스프링 웹 애플리케이션 컨텍스트 내에서 동작함

시점

• 요청 전 : Controller가 요청을 처리하기 전
• 요청 후 : Controller가 요청을 정상적으로 처리한 후(View 렌더링 전)
• 요청 완료 후 : 예외 발생 여부와 무관하게 Controller가 요청을 처리한 후

차이점

• Filter : 스프링 컨텍스트 도달 전/후로 필요한 공통 로직 처리 용도
• Interceptor : 스프링 컨텍스트 내에서 필요한 공통 로직 처리 용도

Error, Exception Handling

예외는 크게 두 가지로 구분

1. 클라이언트 요청에 의한 예외 발생
2. 서버의 로직 처리 과정 중 예외 발생

자세한 에러 발생 부분

Server Error, Exception Handling

웹 서버의 에러

• 서버 자체(네트워크 레벨 등) 문제
• 서버가 요청을 제대로 처리할 수 없는 상황
• web.xml
  • HTTP Status Code 별로 지정된 에러 페이지 반환

웹 애플리케이션에서 예외를 처리할 수 있는 부분

• Filter
  • FilterChain.doFilter() 생략 -> 스프링 컨텍스트 도달 전 예외 처리
  • 직접 HttpServletResponse을 통해 Status Code, Header, Message Body 반환
  • 웹 서버는 Filter에서 처리한 응답을 그대로 클라이언트에게 반환
• Interceptor
  • 시점에 따른 에러 처리
  • 요청 전 에러 처리 : Controller 호출 X, HttpServletResponse로 직접 응답 반환
  • 요청 완료 후 에러 처리 : 클라이언트에게 응답 반환 후 호출되므로 직접 응답 반환 불가, 리소스 정리, 로깅 등 후처리 작업 수행
• Controller, 비즈니스 로직
  • web.xml, Filter, Interceptor, BasicController, @ControllerAdvice 중 선택하여 에러 처리 가능
  • Controller와 그 이후 예외 발생 시 DispatcherServlet에서 처리되지 않은 모든 예외를 Catch함
  • 적절한 @ControllerAdvice, @ExceptionHandler를 검색하고 예외 처리 수행
  • 등록된 Interceptor의 afterCompletion() 호출
• Web Request
  • 클라이언트의 요청이 올바르지 못한 경우(Binding, Validation, HTTP Method, Authentication, Authroization 등)
  • Filter, Interceptor, @ControllerAdvice 등에서 에러 처리

BasicController

• 스프링부트 애플리케이션 내부에서 예외 발생 시 임베디드 웹 서버(Tomcat)까지 예외 전달, 임베디드 웹 서버는 에러 처리를 위해 /error 경로로 요청을 재전송(DispatcherType.ERROR)
• 재전송된 에러 처리 요청은 애플리케이션에서 ErrorController 인터페이스를 통해 에러 처리 가능
• BasicController는 스프링부트에서 제공하는 ErrorController 구현체로 두 가지 동작방식이 있음
  • 클라이언트가 받는 미디어 타입(Accept, produces)이 text/html이라면 View를 찾음
    • 에러 페이지 매핑 : src/main/resources/templates/error 디렉토리 아래에 상태 코드별 에러 페이지 배치
      • 404.html : 404 에러에 대한 HTML
  • 아니라면 ResponseEntity 반환

@ControllerAdvice, @ExceptionHandler

• 에러 처리를 중앙화하여 관리할 수 있는 스프링 어노테이션
• @ControllerAdvice
  • 애플리케이션 전역에서 발생할 수 있는 예외를 잡아 처리하는 클래스에 붙이는 어노테이션
  • 해당 클래스 내에서 @ExceptionHandler 메서드를 통해 특정 예외를 잡아 처리함
• @ExceptionHandler
  • @Controller 클래스 또는 Controller 내부에서 특정 예외를 잡아 처리할 메서드에 붙이는 어노테이션
  • 예외를 처리하고 클라이언트에 응답함
    • Controller와 응답 포맷 동일
    • HTML 응답 : ModelAndView
    • Json 응답 : ResponseEntity
  • 웹 서버까지 예외를 전파하지 않고 스프링 컨텍스트 내에서 예외 처리
• Interceptor
  • Controller와 그 이후에서 발생한 예외의 경우 Interceptor.postHandle()은 호출되지 않고 @ExceptionHandler 처리 과정이 진행된 후 afterCompletion() 호출
  • 다만 Interceptor.preHandle() 내에서 예외가 발생한 경우 @ControllerAdvice로 예외를 잡히지 않는 경우가 있음

HandlerExceptionResolver

• 예외 처리를 위한 스프링 인터페이스
• ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex)
• 반환 값에 따른 동작 방식
  • response.sendError()와 new ModelAndView() : 정상 흐름으로 Servlet 리턴되지만 WAS에게 Error를 알려 예외 처리가 작동됨
  • 특정 ModelAndView : View 렌더링
  • null : 다음 ExceptionResolver 찾아서 실행, 처리할 수 없는 경우 기존 발생한 예외를 Servlet 밖으로 던짐(WAS 예외 처리 동작)
• 구현체(스프링 부트는 HandlerExceptionResolverComposite에 순서대로 자동으로 등록해줌)
  • ExceptionHandlerExceptionResolver : @ExceptionHandler 처리
  • ResponseStatusExceptionResolver : 예외에 따른 response 상태 코드 지정(WAS 예외 처리 동작)
  • DefaultHandlerExceptionResolver : 스프링 MVC 내부 예외 처리(WAS 예외 처리 동작)

비즈니스 로직 예외 처리 workflow

• 해결되지 않은 예외 Controller 밖으로 전파
• DispatcherServlet 예외 확인, 등록된 HandlerExceptionResolver 실행
• ExceptionHandlerExceptionResolver -> Controller 또는 @ControllverAdvice 클래스 내에서 해당 예외 처리 @ExceptoionHandler 메서드 검색 -> 예외 처리
  • 바인딩이나 필드 검증 예외 시(BindingResult가 없는 경우) MessageSource를 통해 메시지 사용 가능(메시지 소스 파일 정의 필요 - MessageCodesResolver의 메시지 코드 변환 규칙 참고)
• @ExceptionHandler로 예외 처리를 하지 못한 경우, HandlerExcpetionResolverComposite에 등록된 다른 Resolver 호출 -> 예외 처리
  • 대부분 WAS에 response 상태 코드를 전달하여 WAS 예외 처리 동작으로 인해 내부 요청 발생
  • 스프링부트의 BasicController 동작 -> 클라이언트 Accept 값에 따라 HTML 페이지 또는 ResponseEntity 응답

Client Request Exception Handling

클라이언트 요청 자체의 에러 종류

• Request Data Error(Binding, Validation Error)
  • 요청 데이터 타입과 요청 처리 메서드 파라미터 타입 불일치
  • 필드 유효성 검증 불만족
  • 비즈니스 유효성 검증 불만족
  • @Valid, @Validated, BindingResult을 통해 처리
• Request format Error
  • HTTP Method 불일치
  • Media Type 불일치(consumes, produces - Content-Type, Accept)
  • HttpMediaTypeNotSupportedException, HttpMediaTypeNotAcceptableException 발생
• Authentication, Authorization Error
  • 스프링 시큐리티 - AuthenticiationError, AccessDeniedException 발생

타입 변환에 실패한 경우 발생할 수 있는 스프링 예외

• MethodArgumentTypeMismatchException
  • Controller 메서드의 파라미터 타입과 클라이언트 데이터 타입 불일치 시 발생
• TypeMismatchException
  • MethodArgumentTypeMismatchException 상위 클래스
  • 프로퍼티, 필드 등의 타입 변환 실패 시 발생
• HttpMessageNotReadableException
  • @RequestBody를 통해 HTTP Request Message Body를 객체로 바인딩할 수 없는 경우 발생
• ConversionFailedException
  • 스프링 ConversionService를 사용하여 데이터 타입 변환을 하다가 실패했을 때 발생
  • MethodArgumentTypeMismatchException보다 더 일반적인 상황에 발생
• 타입 변환 실패는 바인딩 과정 중 예외가 발생하므로 Controller 메서드는 실행되지 않음
  • 이미 Interceptor.preHandle()이 수행된 시점이고, @ExceptionHandler로 발생된 예외를 잡아 처리 가능

@Valid, @Validated

• 바인딩할 클라이언트 데이터를 검증하기 위한 어노테이션
• @Valid : Java Bean Validation - 객체 그래프에 대한 유효성 검사 수행 어노테이션(메서드, 파라미터, 클래스 레벨 적용 가능)
• @Validated : Spring Bean Validation - @Valid와 동일한 기능 제공, 추가적으로 그룹화 유효성 검사 지원

BindingResult

• 클라이언트 데이터를 @ModelAttribute, @ResponseBody를 통해 바인딩하는 과정에서 발생하는 에러를 보관하는 객체
• 요청을 처리하는 Controller 메서드의 @Validated가 적용된 파라미터 뒤에 추가하면 스프링이 바인딩 과정 중 발생한 바인딩, 필드 예외를 캡처함
• 비즈니스 검증 예외의 경우 수동으로 BindingResult에 담아줘야 함
• 글로벌 에러와 필드 에러로 구분해서 처리
  • 글로벌 오류 : 특정 필드에 국한되지 않는 오류
  • 필드 오류 : 특정 필드와 관련된 오류

Validator

• 객체 Validaion 로직을 수행하는 스프링의 인터페이스
• supports, validate 메서드
• @InitBinder, WebDataBinder를 통해 Validator 실행

스프링부트 Validator

• LocalValidatorFactoryBean
• 스프링 부트는 스프링 Bean Validation API를 기반으로 필드 검증을 자동으로 수행하는 글로벌 Validator 제공
• spring-boot-starter-validation 의존성 필요

Method Validation

• @Validated를 메서드 레벨에 적용해서 파라미터와 반환 값에 검증 로직을 추가할 수 있음
• MethodValidationPostProcessor를 통해 메서드 실행 시점에 파라미터나 반환 값에 대한 유효성 검사를 진행
• Bean Validation API 확장 기능
• spring 5.2 ~

ResponseEntityExceptionHandler

• 다양한 예외 유형에 대한 처리 로직을 제공하는 스프링 추상 클래스
• 클래스명 그대로 ResponseEntity 형태로 클라이언트에게 응답
• 기본적으로 스프링 내부 예외를 처리해줌
• 이 클래스를 상속하고 @ControllerAdvice를 적용시켜 전역 예외 처리 클래스로 사용 가능

Message

MessageSource

• 국제화 및 지역화를 위한 메시지 관리 인터페이스(spring core)
• 애플리케이션에서 사용하는 메시지를 프로퍼티 파일에 정의하면, MessageSource를 통해 메시지를 읽어올 수 있음
• getMessage(String code, Object[] args, String defaultMessage, Locale locale)
  • 메시지 코드, 메시지 포맷에 사용될 인자, 기본 메시지, Locale 정보를 받아 적절한 메시지를 반환함
• 구현체
  • ResourceBundleMessageSource : 메시지 소스 파일(.properties)에서 메시지를 로드
  • ReloadResourceBundleMessageSource : 애플리케이션 실행 중 메시지 소스 파일의 변경 사항 반영, 캐싱 기간 설정 가능
  • StaticMessageSource : 테스트용 MessageSource
• MessageSource 타입 스프링 빈 등록 필요(메시지 소스 파일 basename, 기본 인코딩 지정)
• 스프링부트 autoconfiguration : basename을 messages으로 하는 자동 MessageSource 빈 등록
  • messages.properties, messages_en.properties, messages_ko.properties
  • spring.messages.basename 속성으로 추가 메시지 소스 파일 이름 설정 가능

LocaleResolver

• 현재 요청의 Locale을 결정하는 객체, MessageSource와 함께 동작하며 결정된 Locale에 맞는 메시지 제공
• 구현체
  • FixedLocaleResolver
  • AcceptHeaderLocaleResolver
  • SessionLocaleResolver
  • CookieLocaleResolver
• LocalChangeInterceptor : HTTP Request의 특정 파라미터를 기반으로 Locale을 변경할 수 있는 Interceptor

MessageCodesResolver

• 데이터 바인딩 및 검증 과정에서 발생하는 에러 코드를 메시지 코드로 변환하는 인터페이스(spring validation)
• BindingResult 또는 Errors 인터페이스와 함께 동작
• DefaultMessageCodesResolver : 특정 필드에 대한 오류 코드를 바탕으로 메시지 코드 생성
  • 동작 방식(다음과 같은 순서로 메시지 코드 생성)
    • 객체 이름과 필드 이름을 포함한 코드(simpleUser.email.required)
    • 필드 이름만 포함한 코드(email.required)
    • 객체 이름만 포함한 코드(simpleUser.required)
    • 글로벌 코드(required)
• 생성된 메시지 코드는 MessageSource를 통해 실제 메시지 사용 가능

Web Util Object

@InitBinder

• Controller, @ControllerAdvice 클래스 내부에 선언된 메서드에 적용
• 적용된 메서드는 WebDataBinder를 초기화하는 데 사용되며, 요청 핸들러 메서드가 호출되기 전 실행됨

WebDataBinder

• 특정 Controller의 웹 요청 파라미터 -> 객체 바인딩, 프로퍼티 convert, 프로퍼티 format 지정 등을 수행하는 객체
• PropertyEditor, Converter, Formatter, Validator 등록 가능
• 외부 클라이언트로부터 수정되거나 접근하면 안되는 객체 그래프(object graph)의 일부를 노출시켜 보안 문제를 일으킬 수 있음

Data Binding, Type Conversion, Formatting Mechanism

HandlerMethodArgumentResolver

• 클라이언트 요청을 처리할 Controller 메서드의 매개변수를 채워주는 인터페이스
• 매개변수의 타입에 따라 적절한 ArgumentResolver가 선택됨

Converter

• S 타입 <-> T 타입 변환 인터페이스

HttpMessageConverter

• HTTP Request 본문을 Controller 메서드 매개변수 타입에 맞게 변환하는 인터페이스
• @RequestBody, @ResponseBody가 붙은 메서드나 반환 타입에 대해 동작

ConversionService

• 타입 변환을 관리하는 중앙 인터페이스
• 요청받은 타입 변환을 수행할 수 있는 Converter를 찾고 변환 작업 실행

Formatter

• 객체 <-> 문자열 변환 인터페이스
• Converter는 범용, Formatter는 문자열 및 Locale 특화 Converter

FormattingConversionService

• Formatter와 Converter를 모두 관리할 수 있는 구현체
• 스프링부트는 DefaultFormattingConversionService를 상속받은 WebConversionService를 autoconfiguration함
• WebConversionService는 DataBinder에 등록된 Formatter와 Converter를 통해 Request 파라미터의 타입을 변환함

Request Parameters, Annotation

클라이언트에서 데이터를 전송할 수 있는 방법과 스프링에서 받는 방법

Query String Parameters

• URL로 파라미터를 전송하는 방법
• http://localhost:8080?key=value&key2=value2
  • URL 끝에 ?를 붙이고 key=value 파라미터 추가
  • 여러 데이터를 전송할 때는 &로 구분
• 정렬, 필터링, 페이징, 검색 등에 사용
• @RequestParam
  • 메서드 파라미터가 primitive 타입일 경우 생략 가능

Path Parameters

• URL로 파라미터를 전송하는 방법
• http://localhost:8080/QBEUsers/2
  • 각 데이터가 URL 경로에 직접 포함됨
  • RESTful API에서 소스를 지정하기 위해 사용
• @PathVaraible

Form Data

• 사용자가 HTML Form 태그에 입력한 파라미터를 전송하는 방법
• 주요 데이터 형식
  • application/x-www-form-urlencoded : key=value&key2=value2 형태의 텍스트 데이터
  • multipart/form-data : 파일 업로드같은 바이너리 데이터
• @ModelAttribute : Model 데이터를 View에 전달하거나, HTTP Request Parameter를 객체에 바인딩
  • 메서드 파라미터가 객체 타입일 경우 생략 가능
  • 클래스 내의 모든 View에 공통으로 사용될 속성을 Model에 추가해야 될 경우 메서드 레벨에 선언
• @RequestParam

HTTP Message Body

• HTTP 요청 본문에 담는 데이터
• 클라이언트에서 Content-Type: application/json 명시 필요
• @RequestBody : HTTP 요청 본문 데이터(json, xml 등)를 Java 객체로 바인딩
  • HttpMessageConverter를 통해 바인딩

Header Parameters

• HTTP Header에 포함되는 파라미터
• 인증 토큰, 컨텐츠 타입, 언어 설정 등에 사용
• Authroziation: Bearer TOKEN_VALUE
• @RequestHeader

Cookie Parameters

• 웹 서버가 사용자 브라우저에 저장하는 데이터
• 사용자 세션 관리, 개인화 등에 사용
• HTTP 요청 시 Cookie 헤더가 자동으로 전송됨
• @CookieValue

DTO, VO, Command Object

자바 기반 애플리케이션에서 효율적인 데이터 전달 및 표현을 위해 사용되는 패턴이자 개념

DTO(Data Transfer Object)

• 계층 간 데이터 교환을 위한 객체
• DB의 데이터 구조와 클라이언트가 요구하는 데이터 구조 사이에서 적절한 데이터 조정, 전달을 위해 사용됨
• 로직을 갖지 않음
• 각 필드에 대해 getter/setter 포함 가능

VO(Value Object)

• 값을 표현하는 객체
• 값의 집합, 도메인 모델에서 비즈니스 개념을 표현하는 데 사용됨
• 불변성과 동등성에 초점을 맞춤
  • 생성 후 상태 변경 불가능
  • 속성 값이 모두 같을 때 동일하다고 판단

Command Object

• 사용자의 입력(Form)이나 API 요청(Request Message Body)을 통해 전송된 데이터를 처리하는 데 사용되는 객체
• 요청 데이터를 담는 용도, 비즈니스 로직을 처리는 데 필요한 데이터를 Controller로 전달하는 역할
• 검증 로직 포함
• @RequestBody, @ModelAttribute 사용

Spring MVC Workflow

Business Logic Process Workflow

• HTTP Request
• Web Server
• FilterChain
• DispatcherServlet -> HandlerMapping(HandlerExecutionChain)
• DispatcherServlet -> LocalResolver
• Interceptor.preHandle
  • Error
    • Global Exception Processor(@ExceptionHandler)
    • Interceptor.postHandle/afterCompletion call X
• DispatcherServlet -> HandlerAdpter
• HandlerMethodArgumentResolver(FormattingConvesionService, HttpMessageConverter)
• Controller -> Service -> DAO/Repository
  • Business Error or Request Error
  • HandlerExceptionResolverComposite
    • ExceptionHandlerExceptionResolver(@RestControllerAdvice, @ControllerAdvice, @ExceptionHandler) -> HTTP Response
    • ResponseStatusExceptionResolver -> response.sendError -> WAS(/error) -> BasicController -> HTTP Response
    • DefaultHandlerExceptionResolver -> response.sendError -> WAS(/error) -> BasicController -> HTTP Response
• DispatcherServlet -> HttpMessageConveter (@RestController)
  • MappingJackson2HttpMessageConverter
• DispatcherServlet -> ViewResolver (only SSR)
• DispatcherServlet -> View (only SSR)
• Interceptor.postHandle/afterCompletion
  • Error
    • postHandle : Global Exception Processor(@ExceptionHandler), afterCompletion call O
    • afterCompletion : processing X, logging
• FilterChain
• HTTP Response

Web Application Server

Path

ContextPath

• 웹 애플리케이션의 루트 경로
• 웹 애플리케이션이 서버에 배포될 때 여러 애플리케이션이 배포될 수 있음
• 각 애플리케이션을 구분하기 위해 고유한 ContextPath를 지정
• http://localhost:8080/{contextPath}/

ServletPath

• 요청이 도달한 서블릿을 식별하는 경로
• 특정 서블릿이나 컨트롤러가 처리할 요청의 범위를 결정
• http://localhost:8080/{contextPath}/{servletPath}

스프링 부트의 기본 ContextPath, ServletPath

• ContextPath : / (server.servlet.context-path 프로퍼티 설정)
• ServletPath : / (DispatcherServlet)