예외처리 1~3 포스팅에서.. 서블릿 컨테이너가 처리할 수 있는 예외 케이스와 개발자가 보여주고 싶은 에러 페이지를 어떻게 보여줄 수 있는지와 에러페이지 출력을 위한 내부 호출시.. 필터와 인터셉터를 적용 할지말지를 어떻게 처리하는지에 대해 알아 봤다.. 스프링 부트는 위와 같은 복잡한 방법을 간단하게 개발 할 수 있도록 지원해준다. WebServerFactoryCustomizer의 구현체 만들기, 에러페이지 출력을 위한 컨트롤러 개발에 대한 이야기이다. (필터, 인터셉터는 다른 이야기이다..) 이전 포스팅에서 구현한 ErrorPage(객체) 등록은 ErrorMvcAutoConfiguration 에서 처리 하며 상태코드에 따른 구현한 에러페이지(뷰 - html) 매핑 컨트롤러는 BasicErrorCont..

지금까지 예외처리에 대한 포스팅을 보면... WAS - 컨트롤러 간에 왔다갔다 하면서 중간에 있는 필터와 인터셉터가 계속 중복으로 호출된다... 경우에 따라.. 필터와 인터셉터는 중복으로 호출되면 안되는 경우도 있을 것이다.. -> 예를 들면 로그인 체크 로직을 위한 필터나 인터셉션은 이미 최초 정상요청에 의한 호출 로직에서 검증을 했을 것이나.. 에러페이지 출력을 위한 내부 호출에서 불필요한 검증을 하게된다. 그래서 정상요청에 의한 호출인지.. 에러페이지 출력을 위한 내부 호출인지 구분이 필요하다. -> DispatcherType을 사용해보자 DispatcherType 서블릿이 지원하는 enum 이다. REQUEST : 정상요청에 의한 호출일 경우 ERROR : 에러페이지 출력을 위한 내부 호출일 경우..

예외처리 1번 포스팅에서는 서블릿 컨테이너에서 처리 할 수 있는 예외를 알아보았다.. (혹은,, 예외가 발생 했다고 알아볼 수 있는.. 플래그..?) 1. 일반 Exception 2. sendError 메서드 근데.. 톰캣 or 스프링에서 기본적으로 보여주는 뷰를 사용자에게 직접 보여준다는건 좀.. 아니다.. 에러페이지가 너무 성의없는 페이지로 보인다. 개발자가 만들어놓은 에러페이지를 보여주는 방법을 알아보자.. 과거에는 web.xml이라는 파일에 에러페이지를 등록했다.. 서블릿 에러페이지 등록해보기 (스프링 부트가 제공하는 기능을 사용) 스프링 빈으로 해당 객체를 등록해준다. WebServerFactoryCustomizer 를 상속받아 구현하면 된다. ErrorPage 객체를 생성하여 factory에 ..

개발을 하다보면.. 여러가지 예외(exception)가 발생할 수 있다. 먼저 순수 서블릿 컨테이너가 예외를 어떻게 처리하는지 알아보자. 1. 일반 Exception 2. sendError 메서드 기본 지식 위와 같이 error-ex 컨트롤러에 접근하면 런타임 exception을 발생시켜서 던져보자! 그러면... 바로 errorEx 메서드를 호출한 메서드로 넘어가고 그 메서드를 호출한 메서드로 넘어가고 타고타고 계속 넘어간다. (또 예를 들면, java main 함수에서 예외가 발생되면 main 너머로 예외가 던져 진다..) 웹 어플리케이션에서의 예외 발생 WAS -> 필터 -> DispatcherServlet(서블릿) -> 인터셉터 -> 컨트롤러 위는 일반적으로 서버로 요청이 들어오면 호출 되는 순서이..

본 포스팅은 Spring MVC 마스터하기 4와 Spring MVC 마스터하기 인터셉터 1에서 이어집니다. 잠깐 복습! @RequestMapping 컨트롤러를 사용하면 핸들러 어댑터는 RequestMappingHandlerAdapter가 사용된다. RequestMappingHandlerAdapter는 핸들러(컨트롤러)를 호출하기 위해 다양한 파라미터를 만들 필요가 있다. 이때, 컨트롤러에서 사용하는 파라미터를 만들어주기 위해 HandlerMethodArgumentResolver라는 인터페이스를 구현한 구현체들을 호출하여 해당 파라미터를 생성할 수 있다. HandlerMethodArgumentResolver 를 직접 구현해보고 적용해보자.. 이전에는 홈 화면을 보여줄때 로그인 여부를 체크하는 컨트롤러에서...

전 포스팅에서는 서블릿에서 제공하는 필터에 대해 알아봤다.. 이번엔 Spring MVC에서 제공하는 인터셉터에 대해 알아보자.. 스프링 인터셉터도 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 있는 기술이다. 요청/응답 순서도를 다시 한번 알아보자.. 요청이 들어오면.. 요청 -> WAS -> 필터 -> DispatcherServlet -> 인터셉터 -> 각 메서드 컨트롤러의 AOP(Proxy패턴) -> 컨트롤러 응답으로 나갈때는 요청 호출의 역행으로 return 된다. 컨트롤러 -> 각 메서드 컨트롤러의 AOP(Proxy패턴) -> 인터셉터 -> DispatcherServlet -> 필터 -> WAS -> 요청 스프링 인터셉터 순서도에서 볼 수 있듯이.. DispatcherSe..

이전 쿠키 세션 포스팅에서 문제점이 있다.. 로그인을 하지 않은 상태에서 로그인을 해야만 접근 할 수 있도록 의도한 페이지의 URL을 주소창에 직접 타이핑하여 접근을 하면... 접근이 된다! 이러한 문제는.. 로그인 여부를 체크하지 않은 URL로 요청되는 모든 컨트롤러에 모두 해당된다. 공통 관심사로 해결해야한다. -> 그렇지 않으면 모든 컨트롤러에 로그인 여부를 체크하는 로직을 넣어줘야하여 관리가 어려워진다. -> 공통 관심사는 스프링의 AOP로 해결할 수 도 있지만, 웹과 관련된 공통 관심사를 처리 할 때는 이미 서블릿에서 제공하는 필터와 스프링에서 제공하고있는 인터셉터를 사용하는 것이 좋다. 사실 무엇이 좋고 나쁘다는 없다. 스프링을 사용할 수 있을때는 인터셉터, 그렇지 않을 땐 Filter, 비즈..

스프링을 활용하여 세션을 더 편리하게 사용해보자 (기존에는 HttpServletRequest를 파라미터로 받아야해서 번거롭다..) @SessionAttribute 세션 유무에 따른 홈 화면 이전 포스팅의 homeLoginV3 컨트롤러와 비교하여.. HttpServletRequest 파라미터, HttpServletRequest에서 HttpSession 받아오는 부분, HttpSession에서 Member 받아오는 부분이 없어졌다. 대신 @SessionAttribute 어노테이션을 사용하였다. name 요소 : 세션에 저장해놓은 key, value 쌍에서 key를 써준다. required 요소 : 해당 세션이 없어도 되면 false, 세션이 필수이면 true 이다. (false로 하여, 로그인 안한 케이스도..