L.O.K

Bean은 [ 객체 생성 -> 의존관계 주입 -> 스프링 컨테이너 상주 -> 소멸 ] 의 과정을 거친다. Bean은 스프링이 대신 생성해주므로, 초기화 작업과 종료 작업이 원할히 진행 될 수 있도록, 스프링은 의존관계 주입 된 이후와 소멸되기 직전에 개발자가 특정한 로직을 수행시킬 수 있도록 '콜백(CallBack)'을 제공한다. 초기화 작업은 생성자 로직에 포함시킬 수는 있지만 초기화 과정이 무거운 경우, 객체 생성과 초기화 작업을 분리하는 것이 좋다. 이 경우, Spring이 제공하는 초기화 콜백을 사용하는 것이 좋다. 콜백을 제공하는 방식은 3가지가 있다. 1) InitializingBean, DisposableBean 인터페이스 2) @Bean(initMethod = "init", destroyM..

어노테이션으로 스프링 컨테이너에 Bean을 등록하는 방법은 2가지가 있다. 1) 컴포넌트 스캔으로 자동등록 ( @Component, @Service, @Repository ... ) 2) @Configuration 클래스에 수동등록 ( @Bean ) 두 가지 방식은 언제 어떻게 사용하는 것이 좋을까? 1) 업무로직 VS 기술지원 자동방식은 컴포넌트 스캔으로 @Component로 선언된 클래스를 자동으로 Bean으로 등록하니 편하다. 그러나 @Component가 여기저기 퍼져 있어 추적이 힘들다. 수동방식은 @Configuration 클래스를 생성하고 Bean을 하나하나 정의해야 하는 번거로움이 있지만 하나의 클래스에 Bean이 모여 있다보니 관리가 쉽다. 그러므로 자동등록 방식은 업무로직 Bean에 사용..

싱글톤 패턴 가장 단순한 방식으로 싱글톤 패턴이 적용된 클래스는 다음과 같다. 1. Static 영역에 상수로 인스턴스가 생성되어야 한다. 2. 생성자는 private 접근자로 막아놓는다. 3. 인스턴스는 static 메소드로만 외부 접근을 허용한다. public class Box { // 1. statice 영역에 상수로 객체를 생성한다. private static final Box instance = new Box(); // 2. 생성자는 private 접근자로 막아놓는다. private Box(){ } // 3. 인스턴스는 static 메소드로 조회한다. public static Box getBox(){ return instance; } } 웹에서 싱글톤 객체가 중요한 이유는 수많은 Request가..

스프링(Spring)을 사용하는 이유 스프링을 사용하는 이유는 객체(Bean) 생성과 의존관계 주입(DI)을 대신 해주기 때문이다. ( IOC, 제어의 역전 ) 그렇다면, 개발에서 객체생성과 의존관계 주입을 대신 해주는 프레임워크가 필요한 이유는 무엇일까? Spring은 객체지향개발을 도와주는 프레임워크이다. 객체지향개발에서 핵심은 객체 간 결합도를 줄이는 것이다. public class Computer { MouseA mouseA = new MouseA(); // MouseA에 의존, 결합도 증가 public void click(){ mouseA.click(); // MouseA에 의존 } } 컴퓨터 객체가 마우스 객체를 참조하면 클릭 기능을 사용할 수 있다. 그러나 위 코드와 같이, 컴퓨터가 특정 마..

[SpringMVC] API 예외처리하기(2) - HandlerExceptionResolver 컨트롤러에서 에러가 발생하면 복잡해진다. 클라이언트 요청 -> WAS -> 컨트롤러 (에러발생) -> WAS -> 컨트롤러 -> 클라이언트 응답 [SpringMVC] API 예외처리하기(1) - BasicErrorController 위 그림은 Spring에서 lordofkangs.tistory.com 지난 포스팅에서 API 호출에서 발생하는 에러를 처리하기 위해, ExceptionResolver를 직접 만들어 구현해보았다. Controller에서 에러가 발생하면 디스패처 서블릿으로 전파된다. 디스패처 서블릿은 에러가 WAS로 전파되지 않도록 에러를 핸들링 할 수 있는 ExceptionResolver를 탐색한다...

컨트롤러에서 에러가 발생하면 복잡해진다. 클라이언트 요청 -> WAS -> 컨트롤러 (에러발생) -> WAS -> 컨트롤러 -> 클라이언트 응답 [SpringMVC] API 예외처리하기(1) - BasicErrorController 위 그림은 Spring에서 에러가 발생했을 때 처리되는 과정이다. 에러가 발생했을 때 try-catch문으로 Exception을 잡지 않으면 에러는 WAS까지 전달된다. WAS는 에러의 종류를 확인하고 그에 따른 요청을 lordofkangs.tistory.com 그래서 지난 포스팅에서는 위 과정을 자동화 해주는 스프링부트의 BasicErrorController에 대해서 알아보았다. 그러나 API 요청은 다양하고 그에 따라 다양한 에러 응답이 필요하다. BasicErrorCon..

위 그림은 Spring에서 에러가 발생했을 때 처리되는 과정이다. 에러가 발생했을 때 try-catch문으로 Exception을 잡지 않으면 에러는 WAS까지 전달된다. WAS는 에러의 종류를 확인하고 그에 따른 요청을 서블릿에게 재요청한다. 서블릿은 요청과 매핑되는 컨트롤러를 호출하여 오류에 대한 응답을 클라이언트에게 전송한다. 이때 클라이언트가 HTML 응답을 원한다면 에러페이지를 렌더링하여 응답하면 된다. 그런데 클라이언트가 application/json과 같이, HTML이 아닌 다른 방식으로 에러를 응답하기를 바란다면 어떻게 해야 할까? 우선 오류가 발생했을 때, 오류 종류에 따른 WAS 설정을 해보자. WebServerFactoryCustomizer 구현체 @Component public cla..

지난 포스팅에서 오류 페이지가 띄어지는 원리에 대해서 다루어 보았다. HTTP 요청이 들어오면 WAS에서 컨트롤러까지 갔다가, 에러가 발생하면 컨트롤러에서 WAS까지 에러가 전파된 후, WAS는 에러코드에 대응되는 에러페이지 요청을 다시 컨트롤러로 보낸다. 그러면 컨트롤러는 요청에 대응하는 에러페이지를 경로를 뷰템플릿에 반환하여 렌더링하고 클라이언트에게 응답한다. 이 과정을 위해 2가지를 구현해야 했다. 1) 에러페이지 객체 등록 @Component public class WebServerCustomizer implements WebServerFactoryCustomizer { @Override public void customize(ConfigurableWebServerFactory factory) {..

[SpringMVC] 오류페이지 띄우기 ( SpringBoot ) HTTP 요청이 들어오면 위 그림과 같은 순서로 처리가 된다. 만약 여기서 예외가 발생하면 어떻게 될까? try-catch문으로 예외를 처리하면 상관없지만 서블릿 밖으로 예외가 전파되면 예외는 WAS까지 lordofkangs.tistory.com 지난 포스팅에서 오류페이지가 띄워지는 원리를 살펴보았다. 에러 발생 시, try-catch문으로 예외처리가 되지 않으면 에러는 전파되어 WAS까지 전달된다. WAS는 에러코드에 맞는 적절한 에러페이지를 응답해야 한다. 지난 포스팅에서 에러페이지를 띄우기 위한 URL 요청을 다시 서블릿에게 보내도록 설정했다. 그럼 위 그림처럼 다시 WAS->필터->서블릿->인터셉터->컨트롤러로 이동한다. 필터와 인..

HTTP 요청이 들어오면 위 그림과 같은 순서로 처리가 된다. 만약 여기서 예외가 발생하면 어떻게 될까? try-catch문으로 예외를 처리하면 상관없지만 서블릿 밖으로 예외가 전파되면 예외는 WAS까지 올라간다. WAS는 오류페이지를 클라이언트에 응답하는 방식으로 예외를 처리한다. Controller @GetMapping("/error-ex") public void errorEx(){ throw new RuntimeException("예외 발생"); } /error-ex 경로로 요청이 들어오면 RuntimeException을 던져보겠다. application.properties server.error.whitelabel.enabled=false SpringBoot환경의 경우, SpringBoot가 제공..