🚩 3.1 세션과 필터

• 웹은 기본적으로 과거의 상태를 유지하지 않는 무상태(stateless) 연결.
  요청(Request)과 응답(Response)을 하나의 단위로 처리하면서 기존 사용자에 대한 정보는 기억하지 않는다.

• 기존 방문자를 기억하기 위해서 특별한 매커니즘을 사용하게 되는데 세션(HttpSession)⭐이나 쿠키(Cookie)⭐라는 존재. 또는 특정한 문자(토큰)⭐을 이용하기도 한다.

• 로그인 유지를 위한 모든 기능을 웹에서는 세션 트랙킹(session tracking)⭐이다.

🏁 무상태에서 과거를 기억하는 법

• 세션 트래킹(session tracking)⭐ : 과거의 방문 기록을 추적하는 기법.

• HTTP에서 세션 트랙킹은 '쿠키(Cookie)'⭐라는 존재를 이용한다.

• 쿠키는 문자열로 만들어진 데이터의 조각으로 서버와 브라우저 사이에서 요청(Request)이나 응답(Response) 시에 주고받는 형태로 사용된다.

• 쿠키는 기본적인 형태는 '이름(name)'과 '값(value)'의 구조이다. 브라우저에서는 개발자 도구의 '애플리케이션(application)' 메뉴를 이용해서 확인.

• 참고 : GOOGLE의 쿠키 사용법

  • 쿠키는 사용자가 방문한 웹사이트에서 사용자의 브라우저에 전송하는 작은 텍스트 조각입니다.
    쿠키가 있으면 웹사이트에서 사용자의 방문에 관한 정보를 기억하여 다음번에 사이트에 방문했을 때 번거로운 작업을 피하고 더 유용하게 사이트를 활용할 수 있습니다.
    
    브라우저, 앱 또는 기기, 픽셀, 로컬 저장소를 식별하는 데 사용되는 고유 식별자 같은 기타 기술도 이 목적으로 사용될 수 있습니다.

• 쿠키의 시나리오Source: Session vs Token Authentication in 100 Seconds (YouTube)

  1. 브라우저에서 최초로 서버를 호출하는 경우에 해당 서버에서 발행한 쿠키가 없다면 브라우저는 아무것도 전송하지 않는다.
     
     
  2. 서버에서는 응답(Response) 메시지를 보낼 때 브라우저에게 쿠키를 보내주는데 이때 'SetCookie'라는 HTTP 헤더를 이용
     
     
  3. 브라우저는 쿠키를 받은 후에 이에 대한 정보를 읽고, 이를 파일 형태로 보관할 것인지 메모리상에서만 처리할 것인지를 결정한다. 이 판단은 쿠키에 있는 "유효기간(만료기간)"을 보고 판단한다.
     
     
  4. 브라우저가 보관하는 쿠키는 다음에 다시 브라우저가 서버에 요청(Request)할 때 HTTP헤더에 'Cookie'라는 헤더 이름과 함께 전달. (쿠키에는 경로(path)를 지정할 수 있어서 해당 경로에 맞는 쿠키가 전송).
     
     
  5. 서버에서는 필요에 따라서 브라우저가 보낸 쿠키를 읽고 이를 사용한다.
     
     
     쿠키 | 로그인

쿠키를 생성하는 방법

• ❶ 서버에서 자동으로 생성하는 쿠키 : 응답 메시지를 작성할 때 정해진 쿠키가 없는 경우 자동으로 발행

  • WAS마다 고유한 이름이 있으며, 톰켓의 쿠키 이름은 JSESSIONID
  • 브라우저의 메모리상에 보관하며, 브라우저가 종료되면 서버 발행 쿠키도 삭제 된다.
  • 서버에서 발행하는 쿠키의 경로는 /이다.

• ❷ 개발자가 생성하는 쿠키 : 개발자가 생성하는 쿠키는 서버에서 생성되는 쿠키와 다음이 다르다.

  • 이름을 원하는대로 지정
  • 유효기간을 지정할 수 있다. (유효기간이 지정되면 브라우저가 파일 형태로 보관)
  • 반드시 직접 응답(Response)에 추가
  • 경로나 도메인을 지정할 수 있다.(특정한 서버의 경로를 호출하는 경우에만 쿠키를 사용).

🏁 서블릿 컨텍스트와 세션 저장소

• 서버에서 생성하는 쿠키를 이해하기 위해 필요한 개념:
  ❶서블릿 컨텍스트(ServletContext)⭐ ❷세션 저장소(Session Repository)⭐

• 하나의 서버(톰캣)는 여러 개의 웹 애플리케이션(웹 프로젝트)을 실행할 수 있으며, 실제 운영에서도 웹 애플리케이션마다 별도의 도메인을 분리한다.

• 프로젝트의 실행 경로를 '/'외에 다른 이름으로 각각 지정해서 실행하면 하나의 톰캣 내에서 여러 웹 애플리케이션이 실행된다.

• 각각의 웹 애플리케이션은 자신만이 사용하는 고유의 메모리 영역을 하나 생성하여 해당 공간에 서블릿이나 JSP 등을 인스턴스로 만들어 서비스를 제공한다. 이 영역을 서블릿 API에서는 서블릿 컨텍스트⭐라고 한다.

• 각 웹 애플리케이션을 생성할 때 톰캣이 발행하는 쿠키(개발자 생성 쿠키와 구분하기 위해 세션 쿠키⭐라고 함)들을 관리하기 위한 메모리 영역이 하나 더 생성되는 데 이 영역이 세션 저장소(Session Repository)⭐이다.
  
  세션 저장소⭐는 키(key)와 값(value)을 보관하는 구조이다. 이 때 세션 저장소의 키는 톰캣에서 JSESSIONID라는 쿠키 값이 된다.
  
  (😊 아하 톰캣에서 자동 생셩되는 세션 쿠키 JSESSIONID는 랜덤한 문자열 값을 가진다. 브라우저가 웹어플리케이션에 최초 요청을 하면 이 쿠키를 제공하며, 서버의 세션 저장소에는 해당 JESSIONID의 값(value)를 이름으로 하는 키-값을 할당할 수 있는 새로운 공간이 생기는 구나!)
  (브라우저가 톰캣 서버로부터 제공받은 JSESSIONID 쿠키.
  이 JSESSIONID의 밸류값이 세션 저장소에서는 하나의 키key이자 공간의 이름으로 활용되는 것으로 생각하면 된다.)
  서버에서는 브라우저가 가지는 JSESSIONID 쿠키 값을 키key로 보관한다.

  • 톰캣 내부의 세션 저장소는 발행된 쿠키들의 정보를 보관한다.
    문제는 새로운 쿠키가 만들어질 때마다 메모리 공간을 차지한다는 점이다. 자바에서는 GC가 메모리 관리를 해주지만 톰캣에서는 session-timeout 설정을 이용하여 메모리 관리를 한다.
    
    
  • session-timeout 설정 : 지정된 시간보다 오래된 값들은 주기적인 검사과정에서 삭제 (톰캣 서버는 기본 30분)

세션을 통한 상태 유지 메커니즘

• 세션 동작 방식💡

• 코드 상에서 HttpServletRequest의 getSession()⭐이라는 메소드를 실행하면
  톰캣에서는 JSESSIONID 이름의 쿠키가 요청(Request)할 때 있었는지 확인하고 없다면 새로운 값을 만들어 세션 저장소에서 보관한다.
  (😊이미 클라이언트의 요청 헤더에 해당 쿠키가 존재한다면 당연히 새로 만들지는 않을 것이다.)

  • 한 예시로, 3개의 브라우저가 처음으로 세션이 필요한 경로를 요청했다면 서버는 'JSESSIONID-값'으로 이루어진 쌍을 각각 만들어 브라우저에게 제공하고, 서버의 세션 저장소에 해당 JSESSIONID 값을 공간 이름으로 하여 3개의 공간을 생성할 것이다.

• 세션 저장소에서는 JSESSIONID의 값마다 고유한 공간을 가지게 되는데 이 공간은 다시 키key와 값value으로 데이터를 보관할 수 있다.
  
  이 공간들을 이용해서 서블릿/JSP 등은 원하는 객체를 보관할 수 있는데 사용자들마다 다른 객체들을 보관할 수 있다.
  (출처: 자바웹개발워크북 174P)

• 💡 서블릿 API에서는 HttpServletRequest를 통해 getSession()이라는 메소드로 각 JSESSIONID의 공간에 접근할 수 있다.

프로젝트의 생성과 복사 175P

HttpServletRequest의 getSession( )

• HttpServlet의 getSession()은 브라우저의 요청 정보를 이용해서 다음 작업을 수행한다.

  • JSESSIONID가 없는 경우 : 세션 저장소에 새로운 번호로 공간을 만들고 해당 공간에 접근할 수 있는 객체를 반환. 새로운 번호는 브라우저에 JSESSIONID 값으로 전송
  • JSESSIONID가 없는 경우 : 세션 저장소에서 JSESSIONID값을 이용해서 할당된 공간을 찾고 이 공간에 접근할 수 있는 객체를 반환

• HttpServlet의 getSession()의 결과물 : 세션 저장소 내의 공간.

  • HttpSession 타입 : 이 공간을 의미하는 타입
  • 세션 컨텍스트(Session Context) 혹은 세션(Session) : 이 공간 자체 (키-밸류 쌍을 저장할 수 있음. 키의 예시로는 로그인 정보, 사용자 정보, 권한 정보)

- 등록할 때, 로그인 체크하기

• TodoRegisterController의 doGet() 수정
  

  • HttpSession session = req.getSession() : JSESSSIONID가 없는 경우 세션 저장소에 JSESSIONID의 값을 이름으로 하는 공간을 만들고 JSESSIONID-값 쌍의 쿠키를 브라우저에 전송한다. 단, JSESSIONID가 기존 브라우저 쿠키에 존재할 경우 세션 저장소에서 이 값으로 할당된 공간을 찾고 해당 공간에 접근할 수 있는 객체를 반환한다.
    -> 이 경우에는 그 객체의 주소값이 session에 할당되었다.
    
    
  • session.isNew() : 해당하는 세션이 새롭게 만들어진 공간인지 체크한다.(JSESSIONID 쿠키가 기존에 없었던 새로운 사용자임을 체크)
    
    
  • session.getAttribute("loginInfo") == null : SESSIONID는 있지만 해당 세션 컨텍스트에(ㅡ 그러니까 세션 공간에) 로그인 정보가 없는 경우를 의미한다.

• 응용 프로그램 개발자 도구에서 응용 프로그램 항목의 JSESSIONID 쿠키를 삭제하고 다시 todo/register 요청을 보내면 어떻게 될까?
  

  • 새로운 값이 할당되어 브라우저로 전송된다.
    (물론 서버의 세션 저장소에는 해당 값을 이름으로하는 공간이 생겼을 것이다.)
    

• 만약 기존에 해당 SESSIONID가 있다면 어떻게 될까?

  • 해당 쿠키의 값을 이름으로 하는 세션 저장소는 존재하지만 (!session.isNew()) 그 세션 저장소에 로그인 정보는 없기 때문에 다음 로그가 출력된다.

- 로그인 처리 컨트롤러 작성하기 181

• LoginController.java 의 doGet() 오버라이딩

• WEB-INF/login.jsp 로 화면단 연결

• LoginController.java 의 doPost() 오버라이딩

  • 1. req.getParameter(아이디), req.getParameter(비번) 으로 문자열 만든 다음
  • 2. req.getSession() 사용하여 세션 저장소 최초 생성하며
       해당 HttpSession 객체로 setAttribute("로그인 정보", 로그인 정보 문자열)를 하여 세션 저장소에 키-값 저장.
  • 3. todo/list.jsp로 sendRedirect할 때 JSESSIONID쿠키 정보가 전송될 것이다.
  • 4. 이제 로그인 정보가 브라우저의 쿠키와 세션 저장소를 통해 확인 가능하므로 TodoRegisterController의 doGet()을 통해 resp.sendRedirect("/login")에 대한 뷰 접근이 가능하다.

- 필터를 이용한 로그인 체크 184

• 로그인 여부를 체크하는 컨트롤러마다 동일하게 체크 로직을 작성하면 코드의 중복이 발생하며, 비효율적이다.
  ➡️ @WebFilter로 공통 관심사를 분리한다. (웹 MVC 패턴에서)

  • @WebFilter⭐ : 특정 경로에 접근할 때 필터가 동작하도록 설계할 수 있다.
    
    필터는 한 개 이상, 여러 개를 적용할 수 있어서 여러 개의 필터를 적용할 수도 있다.
  • Servlet 3.0 이상 사용 가능
    톰캣 7이상에서 사용 가능

• filter.LoginCheckFilter.java 생성

- UTF-8 처리 필터 188

• filter.UTF8Filter

- 세션을 이용하는 로그아웃 처리 189

• controller.LoginController.java

- 데이터베이스에서 회원 정보 이용하기 191

• webdb에 tbl_member 테이블 생성.

- 자바에서 회원 데이터 처리하기 192

• domain.MemberVO.java 작성

• dao.MemberDAO.java 작성

  • Member getWithPassword(String mid, String mpw) : API 계층에서 받아온 mid와 mpw로 쿼리 조작하여 DB에서 해당 결과를 가져온다. 그 ResultSet에서 MemberVO를 빌더 패턴으로 생성하여 다시 리턴한다.

• dto.MemberDTO.java 작성 : 서비스 계층과 컨트롤러에서 사용할 DTO

• service.MemberService 작성 : MemberDTO를 사용, DAO와 ModelMapper 를 필드로 가지고 있음.
  enum을 이용한 싱글톤 패턴으로 MemberService 클래스 작성

  • MemberDTO login(String mid, String mpw) throws Exception : dao 객체를 통해 해당하는 MemberVO를 DB에서 얻어오고 modelMapper.map을 통해 VO -> DTO 작업하여 해당하는 memberDTO 작성

- 컨트롤러에서 로그인 연동 196

• controller.LoginController.java 에서 doPost()메서드가 MemberService를 연동해 실제로 로그인 되도록 코드 작성

  • 정상적으로 로그인 된 경우 HttpSession을 이용해서 'loginInfo' 이름으로 객체를 저장
  • 예외가 발생하는 경우 /login으로 이동하며 클라이언트에게 해당 정보를 알리기 위해 쿼리파라미터로 ?result=error 전송

EL에서 쿼리 스트링 처리

• /WEB-INF/login.jsp에는 EL을 기본적으로 제공하는 param이라는 객체를 이용해서 result라는 이름으로 전달한 값을 확인할 수 있다.

  • login.jsp는 JSTL을 이용해 ${param.result}가 error라면 다른 문구를 보여주도록 출력한다.

- EL의 Scope에서 HttpSession접근하기

• EL을 이용해서 HttpServletRequest에 setAttribute()로 저장한 객체를 사용할 수 있다.
  
  EL은 스코프라는 변수의 범위를 가지고 있는데,
  Page Scope, Request Scope, Session Scope, Application Scope를 순차적으로 탐색하며 ${어쩌구}에 해당하는 객체나 값을 가져온다.

  • 예제에서는 HttpSession을 이용해서 loginInfo라는 이름으로 MemberDTO를 저장했는데, 이전과 동일하게 ${loginInfo}를 사용해 접근할수 있다. (😊이전에는 세션이 아닌 HttpServletRequest 객체에 저장을 했었죠.)

---

🚩 3.2. 사용자 정의 쿠키(Cookie)

• ⭐사용자 정의 쿠키와 WAS에서 발생하는 쿠키(세션 쿠키)의 차이 : 자바웹개발워크북 200p

• 사용자 정의 쿠키를 생성할 때는 newCookie()를 이용해서 생성한다. 이 때 반드시 문자열로 된 이름(name)과 값(value)가 필요하다. 값(value)은 일반적인 문자열로 저장이 불가능하여 URLEncoding된 문자열로 지정해야 한다. (한글 저장 불가)

쿠키를 사용하는 경우

• 쿠키는 서버와 브라우저 사이를 오가기 때문에 보안에 취약하다.

• 오랜 시간 보관하는 데이터는 항상 서버에 보관하고,
  약간의 편의를 제공하기 위한 데이터는 쿠키에 보관한다.

  • '오늘 하루 이 창 열지 않기', '최근 본 상품 목록'
  • 모바일에서의 '자동 로그인'

- 조회한 Todo 확인하기 201

• Todo 목록에서 조회했던 Todo 번호(tno)들을 쿠키를 이용해서 보관할 수 있다.

  • 브라우저에서 전송된 쿠키가 있는지 (서버에서) 확인 - 있다면 해당 쿠키의 값(value)을 활용하고 없다면 새로운 문자열을 생성
  • 쿠키 이름은 'viewTodos'
  • 문자열 내에 현재 Todo의 번호를 문자열로 연결
  • '3-4-5' 같은 형태. 이미 조회한 번호는 추가X
  • 쿠키의 유효기간 24시간으로 지정하고 쿠키를 담아서 전송

• controller.TodoReadController.java에 다음 코드 추가

  • 현재 요청(Request)에 있는 모든 쿠키 중에 조회 목록 쿠키(viewTodos)를 찾아내는 메소드
  • 특정한 tno가 쿠키의 내용물이 있는지 확인하는 코드

• doGet()에서 변경된 부분 'viewTodos' 이름의 쿠키를 찾고(findCookie()), 쿠키의 내용물을 검사한 후에 조회한 적 없는 번호라면 쿠키의 내용물을 갱신해서 브라우저로 보내주는 것.

• ⭐쿠키를 변경할 때는 다시 경로나 유효시간을 세팅해야 한다.

- 쿠키와 세션을 같이 활용하기 204

• 현재 /todo/..로 시작하는 모든 경로에 대해서 로그인이 필요하기 때문에 매번 로그인해야 하는 불편함이 있다.

• 쿠키를 이용한 자동로그인 'remember-me'를 고려해 볼 수 있다.

  • 쿠키 이용 자동 로그인 : 로그인한 사용자 정보를 쿠키에 보관하고 이를 이용해서 사용자 정보를 HttpSession에 담는 방식
    
    단, 사실 제대로 remember-me를 구현하기 위해서는 스프링 부트, 시큐리티의 개념이 필요하다. 여기서는 아이디어만.

자동로그인 준비

• 자동로그인을 위해서는 ❶쿠키에 어떤 값을 보관할 것인지 ❷유효시간은 어떻게 할지 고려

• 로그인 구현 방식

  • 사용자가 로그인할 때 임의의 문자열을 생성하고 이를 DB에 보관
  • 쿠키에는 생성된 문자열을 값으로 삼고 유효기간은 1주일로 지정

• 로그인 체크 구현 방식

  • 현재 사용자의 HttpSession에 로그인 정보가 없는 경우에만 쿠키를 확인
  • 쿠키의 값과 DB를 비교하고 같다면 사용자 정보를 읽어와서 HttpSession에 사용자 정보 추가

• 쿠키와 값을 탈취당하는 리스크를 조금 더 안전하게 하기 위해서 주기적으로 쿠키의 값을 갱신하는 부분이 추가되어야 한다.
  
  여기서는 우선 UUID를 이용한 임의의 문자열을 이용한다. UUID(universally unique identifier)⭐는 범용 고유 식별자로 고유한 번호를 랜덤으로 생성할 때 사용한다. (자바 java.util 패키지)

• tbl_member 테이블에 임의의 문자열 보관을 위한 uuid 칼럼을 추가한다.
  alter table tbl_member add column uuid varchar(50)

- 자동 로그인 처리 205

• login.jsp : 자동 로그인 여부를 묻는 체크박스 추가하여 구성 (name ="auto")

• LoginController.java의 doPost()에서는 'auto' 체크 여부를 boolean 값에 담아 해당 boolean이 true이면 java.util의 UUID를 이용해서 임의의 번호 생성
  String uuid = UUID.randomUUID().toString()

• MemberVO, MemberDTO에 새로 추가된 열 uuid 반영

• MemberDAO에 추가 기능 작성 : rememberMe가 true라면 tbl_member 테이블에 사용자 정보에 uuid를 수정하도록 한다.

  • public void updateUuid(String mid, String uuid) : rememberMe가 true이면 tbl_member 테이블 갱신

• MemberService에도 연결 메소드 작성

  • public void updateUuid(String mid, String uuid)
    : 내용은 dao.updateUuid(mid, uuid)

• LoginController의 doPost()에는 로그인 후에 반영

쿠키 생성 및 전송 209

• 쿠키에 들어가야 하는 문자열이 제대로 처리되었다면 이제 브라우저에 remember-me 이름의 쿠키를 생성해서 전송

쿠키의 값을 이용한 사용자 조회 210

• 쿠키 안에 UUID로 생성된 값을 저장했다면 (remember-me)쿠키의 값을 이용해서 해당 사용자 정보를 로딩해 오는 기능도 필요하다.

• MemberDAO에 public MemberVO selectUUID(String uuid) 추가

  • DB에서 uuid를 바탕으로 쿼리문의 결과를 받아와서 builder 패턴으로 VO 생성하여 DTO에 반환

• MemberService에도 public MemberDTO getByUUID(String uuid) 작성

  • dao에서 uuid로 얻어온 VO 객체는 이 메서드에서 DTO로 다시 매핑되어 리턴된다.

LoginCheckFilter에서의 쿠키 체크

• 이전 LoginCheckFilter.java 클래스에 구현된 기능 :
  ❶HttpSession에 loginInfo라는 이름으로 객체가 저장된 것인지 확인하는 기능

• 새롭게 추가해야할 기능:
  ❷ HttpSession에는 없고, 쿠키에 UUID 값만 있는 경우

• 로그인 체크 전체 진행과정

  1. HttpServletRequest를 이용해서 모든 쿠키 중에서 remember-me이름의 쿠키 검색
     
     
  2. 해당 쿠키의 value(UUID) 이용해서 MemberService를 통해 MemberDTO 구성
     
     
  3. HttpSession을 이용해서 'loginInfo'라는 이름으로 MemberDTO를 setAttribute()
     
     
  4. 정상적으로 FilterChain의 doFilter() 수행

• LoginCheckFilter에 코드 개선 적용 이후 결과

  • HttpSession 내에 loginInfo로 저장된 객체도 없고, remember-me 쿠키에도 아무것도 없는 상황 : 로그인 경로로 리다이렉트 처리
    
    
  • HttpSession에는 없지만 쿠키만 존재하는 경우:
    DB에 uuid가 존재하고 쿠키가 전송된다면 정상적으로 로그인 처리

• 단, 주기적으로 UUID 값을 바꾸는 방식을 적용해서 더 안전한 자동 로그인을 구현하는 것을 고려해야 함.

🚩 3.3. 리스너(Listener)

• 스프링 MVC는 리스너를 통해서 동작한다.
• 서블릿 API의 리스너(Listener)⭐
  : 리스너 객체는 이벤트(Event)라는 특정 데이터가 발생하면 자동으로 실행되는 특징이 있다.

🏁 리스너의 개념과 용도 215

• 어떤 작업의 영향으로 다른 작업이 같이 실행되어야 하는 경우 이벤트 리스너를 사용한다.

  • ex) 현재 서버에 접속한 모든 사용자의 IP를 로그로 남겨야 하는 경우

• 옵저버(observer) 패턴⭐ :
  특정한 변화를 '구독(subscribe)'하는 객체들을 보관하고 있다가 변화가 발생(발행, publish)하면 구독 객체를 실행

  • ex) 재난 감시 시스템

• 서블릿 API는 여러 이벤트(Event)에 맞는 리스너를 인터페이스로 정의해 두었다. 이를 이용해서 다음 작업을 처리할 수 있다.

  • 해당 웹 애플리케이션이 시작되거나 종료될 때 특정한 작업을 수행
  • HttpSession의 특정 작업에 대한 감시와 처리
  • HttpServletRequest에 특정한 작업에 대한 감시와 처리

ServletContextListener 216

• ServletContextListener⭐: 어떤 프로젝트가 실행되자마자 실행되어야 하는 작업을 처리

  • 리스너 클래스에 @WebListener 애너테이션 붙임.
  • ServletContextListenr 구현
  • void contextInitialized(ServletContextEvent sce) 와
    void contextDestroyed(ServletContextEvent sce)의 추상메서드를 구현

ServletContextEvent와 ServletContext 217

• contextInitailized()와 contextDestroyed()에 파라미터로 특별 객체인 ServletContextEvent라는 객체가 전달된다.

• ServletContextEvent⭐를 이용하면 현재 애플리케이션이 실행되는 공간인 ServletContext에 접근할 수 있다.

• ServletContext에도 Http요청객체나 Http세션 객체 등과 마찬가지로 어떠한 속성을 키-밸류로 지정할 수 있다.

  • ServletContext에 저장되는 객체는 서블릿 JSP/EL에 공유해서 사용할 수 있다.
    (😊전역변수 느낌)

• HttpServletRequest에는 getServletContext() 메서드를 이용해서 ServletContext를 이용할 수 있다.

ServletContextListener와 스프링 프레임워크

• ServletContextListener와 ServletContext를 이용하면 프로젝트가 실행될 때 필요한 객체들을 준비하는 작업을 할 수 있다.

  • 예) 커넥션 풀 초기화 / TodoService와 같은 객체를 미리 enum으로 생성해서 보관 등

• 스프링 프레임워크를 웹 프로젝트에서 미리 로딩하는 작업을 처리할 때 ServletContextListener를 이용한다.

- 세션 관련 리스너

• 서블릿의 리스너 중에서 HttpSession 관련 작업을 감시하는 리스너를 등록할 수 있다.

  • HttpSessionListner나 HttpSessionAttributeListener를 이용해서 HttpSession이 생성되거나 setAttribute()등의 작업이 이루어질 때 이를 감시할 수 있다. (감시하여 이 사건이 발생하면 로그를 출력할 수도 있다.)

1. HttpSessionAttributeListener를 구현 한다.

2. 클래스레벨에 @WebListener 애너테이션을 붙인다.

3. attributedAdded(), attributedRemoved(), attributedReplaced()를 이용해서 HttpSession에 setAttributed()나 removeAttribute() 등의 작업을 감지할 수 있다.

   • 이 메서드들을 구현하면 인자로 HttpSessionBindingEvent 객체를 전달받는데 이 객체의 getName()과 getValue()를 통해 추가/삭제된 속성의 키-밸류 값을 확인할 수 있다.