Backend/Spring (19) 썸네일형 리스트형 HttpMessageConverter, ArgumentResolver, MappingJackson2HttpMessageConverter(JSON을 이용한 @RequestBody/@ResponseBody의 동작 원리) @RequestBody는 클라이언트 측에서 보낸 HTTP 요청 메시지 바디의 데이터를 자바 객체로 변환해준다. 그리고 @ResponseBody는 객체 반환시 객체가 JSON 형태로 변환되어 응답이 나가도록 해준다. 이들의 동작 원리를 이해하기 위해서는 직렬화/역직렬화의 개념과 스프링 MVC에서 제공하는 HttpMessageConverter에 대해 알아야 한다. 직렬화/역직렬화 직렬화(Serialization)는 객체를 문자열 또는 바이트 스트림으로 변환하는 것을 의미한다. 반대로 역직렬화(Deserialization)는 문자열 또는 바이트 스트림을 다시 객체로 변환하는 것을 의미한다. 즉 @RequestBody는 클라이언트 측에서 보낸 HTTP 요청 메시지 바디의 데이터를 자바 객체로 변환하는 역직렬화.. 서블릿의 예외 처리, 스프링의 예외 처리(HandlerExceptionResolver) 서블릿의 예외 처리 서블릿의 예외 처리 흐름 먼저 스프링이 아닌 순수 서블릿 컨테이너는 어떻게 예외 처리를 하는지 알아보자. 서블릿은 다음 2가지 방식의 예외 처리를 지원한다. Exception 순수 자바 프로그램의 경우, 자바의 main 메서드를 직접 실행하면 main이라는 이름의 스레드가 실행된다. 그리고 실행 도중에 발생한 예외를 잡아서 처리하지 않으면 처음에 실행한 main 메서드까지 예외가 넘어가고, 예외 정보를 남기며 해당 스레드는 종료된다. 반면, 웹 애플리케이션은 사용자 요청별로 별도의 스레드가 할당되고 서블릿 컨테이너 안에서 실행된다. 만약 컨트롤러에서 예외가 발생했는데 이를 잡지 못하면 어떻게 될까? 예외 발생시 흐름은 다음과 같다. WAS(여기까지 예외 전파) ⬅️ 필터 ⬅️ 서블릿 .. Filter, Interceptor Filter 필터는 서블릿이 지원하는 기능이다. 필터는 다음과 같은 특징을 갖는다. 필터의 흐름: HTTP 요청 ➡️ WAS ➡️ 필터 ➡️ 서블릿(디스패처 서블릿) ➡️ 컨트롤러 즉, 디스패처 서블릿의 앞 단에서 필터가 동작하기 때문에, 필터는 스프림 범위 밖에서 처리되는 것이다. (스프링의 시작이 디스패처 서블릿이라고 이해하면 된다.) 즉, 스프링 컨테이너가 아닌 톰캣과 같은 서블릿 컨테이너에 의해 관리된다. Filter 등록 필터를 사용하려면 Filter 인터페이스를 구현하고, 해당 객체를 필터로 등록해야 한다. 그러면 서블릿 컨테이너가 필터를 싱글톤으로 생성하고 관리한다. Filter 인터페이스 public interface Filter { default void init(FilterConfig .. Spring MVC의 구조(DispatcherServlet, HandlerMapping, HandlerAdapter) DispatcherServlet public class DispatcherServlet extends FrameworkServlet {} DispatcherServlet은 표현 계층 전면에서 HTTP 프로토콜을 통해 들어오는 모든 요청을 가장 먼저 받아 공통 작업을 처리하고, 적합한 컨트롤러에게 요청을 위임해주는 프론트 컨트롤러이다. 즉, 클라이언트로부터 어떠한 요청이 오면 톰캣과 같은 서블릿 컨테이너가 요청을 받는다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿에게 보낸다. 그러면 디스패처 서블릿은 공통적인 작업을 처리한 후에 해당 요청을 처리해야 하는 컨트롤러를 찾아서 요청을 위임한다. DispatcherServlet의 상속 관계는 다음과 같다. 즉, DispatcherServlet도 결.. Web Server, WAS, Servlet Web Server 웹 서버는 클라이언트가 웹 브라우저에서 어떠한 페이지 요청을 하면 웹 서버에서 그 요청을 받아 정적 컨텐츠를 제공하는 서버이다. 여기서 정적 컨텐츠란 html 문서, css, 자바스크립트, 이미지, 영상 등 즉시 응답 가능한 컨텐츠이다. 동적인 컨텐츠 요청시에는 WAS에게 클라이언트의 요청을 전달하고, WAS가 처리한 결과를 클라이언트에게 전달한다. WAS(Web Application Server) WAS는 웹 서버의 기능을 포함하여 정적 컨텐츠를 제공할 뿐만 아니라, DB 조회나 비즈니스 로직 처리 등을 요구하는 동적 컨텐츠도 제공하는 애플리케이션 서버이다. 즉 WAS는 "Web Server + Web Container(Servlet Container)"라고 정의하기도 한다. 그래서.. 빈 스코프 빈 스코프는 빈이 존재할 수 있는 범위를 뜻한다. 스프링은 다음과 같은 스코프를 지원한다. 싱글톤: 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다. 프로토타입: 스프링 컨테이너가 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는, 매우 짧은 범위의 스코프이다. 웹 관련 스코프: request: HTTP 요청 하나가 들어오고 나갈 때까지 유지된다. 각각의 HTTP 요청마다 별도로 빈 객체가 생성되고 관리된다. session: HTTP Session과 동일한 생명주기를 갖는다. application: 웹의 서블릿 컨텍스트와 동일한 생명주기를 갖는다. websocket: 웹 소켓과 동일한 생명주기를 갖는다. 싱글톤 스코프 싱글톤 빈은 스프링 컨테이너 생성 시점에 .. 빈 생명주기 콜백을 통한 스프링 빈 객체의 초기화/종료 작업 데이터베이스 커넥션 풀이나 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고 애플리케이션 종료 시점에 연결을 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다. 객체의 초기화는 스프링 컨테이너에 해당 객체가 스프링 빈으로 생성되고 의존관계 주입이 완료된 후에 진행해야 하고, 객체의 종료는 해당 객체의 빈이 소멸되기 직전에 진행해야 한다. 참고로 객체가 스프링 빈으로 생성된 후에 객체의 초기화 작업을 해야 하는 이유는 다음과 같다. 생성자는 필수 정보를 파라미터로 받고 메모리를 할당해서 객체를 생성하는 책임을 가진다. 반면 초기화는 이렇게 생성된 객체를 외부 커넥션과 연결하는 등 무거운 동작을 수행한다. 따라서 생성자 안에서 무거운 초기화 작업까지 함께 하는 것보다는 객.. 스프링 빈 등록과 조회 스프링 컨테이너에서 빈 조회 다음 메소드를 통해 스프링 컨테이너에 있는 빈을 조회할 수 있다. getBeanDefinitionNames(): 스프링에 등록된 모든 빈 이름을 조회한다. 따라서 사용자가 정의한 빈 외에 스프링이 내부에서 사용하는 빈들도 함께 조회된다. 스프링이 내부에서 사용하는 빈은 제외하고 사용자가 등록한 빈만 조회하려면, getRole() 메소드를 통해 빈을 구분하면 된다. ROLE_APPLICATION` : 일반적으로 사용자가 정의한 빈 ROLE_INFRASTRUCTURE` : 스프링이 내부에서 사용하는 빈 getBean(): 빈 이름 또는 타입으로 빈을 조회한다. (ex, getBean("memberService", MemberService.class)) 조회하려는 빈이 없으면 No.. 이전 1 2 3 다음
