하루하루는 성실하게 인생 전체는 되는대로

# 진행 순서 사용자 요청(Request) -> Servlet Filter -> Dispatcher Servlet -> Interceptor -> Controller 1. WebMvcConfigure 클래스 생성 (WebMvcConfigurer를 implements로 상속받음) : WebMvcConfigure가 제일 앞단에서 사용자의 HttpRequest를 잡아 처리해줄 것이다. - @ComponentScan (패키지 경로)로 interceptor에 대한 componentScan이 가능하도록 지정해주었다. - @EnableWebMvc : dispatcherServlet 생성시 필요한 config들을 알아서 생성해준다. (interceptor도) - JwtAuthProvider를 final로 선언. Aut..

JWT 유저를 인증, 식별하기 위한 토큰 기반의 인증. 서버에 저장되는 세션과 달리, 토큰은 클라이언트에 저장되어 서버 부담 덜 수 있다. 토큰 자체에 사용자의 권한 정보, 서비스 사용정보가 포함된다. 따라서 데이터 많아지면 토큰도 커진다. 한번 발급된 이후 사용자 정보 바꾸더라도, 토큰 재발급하지 않는 한 반영되지 않는다. JWT에는, 이름처럼 JSON 데이터를 Base64 URL-safe Encode를 통해 인코딩하여 직렬화한 것이 포함되며, 토큰 내부에는 위변조 방지 위해 개인키를 통한 전자서명도 존재한다. RESTful과 같은 무상태(stateless) 환경에서 사용자 데이터를 주고 받을 수 있게 된다. (세션의 경우, 쿠키 등을 통해 식별하고 서버에 세션 저장했지만, JWT 같은 토큰을 사용하면..

full gc가 동작하여 heap메모리가 95퍼 이상 치솟는 상황이 발생했다. full gc와 JVM메모리 구조에 대한 개념을 다시한번 집고 넘어가고자 한다. GC(가비지 콜렉터) java 어플리케이션에서 사용하지 않는 메모리를 자동으로 수거(=삭제)하는 기능 * 가비지 : java에서 객체=쓰레기(가비지)이다. 하나의 객체가 만들어지면 메모리를 점유하는데, 특정 메소드 수행 완료한 후 필요없어진 객체는 쓰레기(가비지)가 되기 때문. => 이 쓰레기 객체, 가비지를 처리하는 작업을 GC라고 한다. 수동으로 관리해줘야하는 c언어와 달리, java에서는 GC 알고리즘이 메모리를 automatic하게 관리해줌. (개발자가 손댈 필요도, 손댈 수도 없음) * Stop-the-world : GC를 실행하기 위해,..

오늘 예외처리가 얼마나 중요한지, 또 자바스러운 구조가 생산성 자체에 기여하는 바가 얼마나 큰지에 대해 다시 한 번 새삼스레 깨닫게 되는 일이 있었다. 협력사로부터 전달받은 코드를 배포하여 테스트를 진행할 때에 로그 상에 큰 이상이 없어서 문제가 없다고 생각했다. 하지만 해당 서버 담당자로부터 배포 이후 err 푸시알림이 주기적으로 발생하고 있다는 안내를 전달받았고, 밤늦은 시간인지라 서둘러 롤백 후 대충이나마 코드를 뜯어보았다. 일단 뭐가 문제인지 파악하기 전에 err의 흔적이 로그에 남지 않았던 이유를 바로 알아챌 수 있었는데, 협력사에서 추가한 메서드에 try-catch문이 존재하지 않았기 때문으로 유추되었다. 자바 초심자인 나로써도 try-catch가 중요하다는 것을 알고 있는데 이걸 빠트리다니...