서블릿 예외 처리 서블릿 예외 처리 방식 Exception Response.sendError(HttpStatus.StatusCode, "ErrorMessage") 1. Exception 컨트롤러에서 발생한 예외는 인터셉터 -> 서블릿 -> 필터를 거쳐 WAS까지 반환됨 WAS로 예외가 올라오는 경우 Tomcat이 기본으로 제공하는 오류 화면을 볼 수 있다. p.s) 이를 보기 위해 whitelabel 에러 페이지 생성 기능을 꺼두었다. 2. response.sendError(HttpStatus.상태코드, "errmsg") HttpServletResponse가 제공하는 .sendError()메서드를 사용하는 방법도 있다. 서블릿 컨테이너에게 오류가 발생한 것을 전달할 수 있다 이 메서드는 HttpStatu..
스프링 Interceptor 도입 스프링 인터셉터도 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 잇다. 서블릿 필터 - 서블릿에 의해 제공 스프링 인터셉터 - 스프링 MVC에 의해 제공. 둘 다 공통관심사항 처리가 가능하다는 점에서 비슷하지만 적용되는 순서/범위/사용법은 다르다 스프링 인터셉터 처리 흐름 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 스프링 인터셉터는 DispatcherServlet(프론트 컨트롤러)와 컨트롤러 사이에서 컨트롤러 호출 직전에 호출된다. 스프링 인터셉터는 스프링 MVC가 제공하는 기능이기 때문에 결국 디스패쳐 서블릿 이후에 등장한다. 스프링 인터셉터에도 urlPatterns를 적용할 수 있는데 서블릿의 url..
이전까지 로그인 기능 자체는 구현했지만 아직까지 구현되지 않은 부분이 있다 URL에서 /items로 접근하면 로그인 된 사용자만 접근 가능하도록 구현을 변경해야하는데 /items 상에 검증 로직을 적용하지 않았기 때문에 로그인 여부와 관계없이 정상적으로 접속되는 것을 알 수 있다. 컨트롤러상에서 이 기능을 구현하려면 전체 컨트롤러 메서드마다 검증 로직을 구현해야하는데 중복되는 코드가 많아 코드 복잡성이 올라간다 이러한 복잡성을 완화하기 위해 서블릿은 필터 기능을, 스프링 MVC는 인터셉터 기능을 제공한다. 공통 관심사의 경우 이전에 공부한 스프링 AOP로도 구현할 수 있으나 이 기능은 웹과 관련된 내용이기 때문에 MVC 상에서 해결하는게 좋다. 서블릿 필터 필터는 서블릿이 제공하는 수문장과 비슷한데 전체..
HTTPSession - 1 SessionManager와 같은 방식으로 스프링은 HttpSession 기능을 지원한다. 단 이 때 쿠키 이름은 표준 값에 의해 JSESSIONID에 해당하고 값은 추정 불가능한 랜덤 값이다. HTTPSession의 사용 package hello.login.web; // 추상클래스 VS 인터페이스로 사용하라 public abstract class SessionConst { public static final String LOGIN_MEMBER = "loginMember"; } HttpSession에 데이터를 보관하고 조회할 때 같은 이름이 중복되어 사용되므로 상수를 하나 정의함. @PostMapping("/login") public String loginFormV3(@Val..
