스프링 Ch 6-5 Filter / Interceptor - 패스트캠퍼스 챌린지 11일차

이번에는 앞단에서 핸들러로 요청/응답이 가기 전에 먼저 낚아채는 방법을 배웁니다.

방법은 두 가지입니다.

• Filter 인터페이스 구현 (및 컴포넌트로 밀어넣기):
  • 앞단에서 ServletRequest / ServletResponse 를 조작할 수 있습니다.
  • 날것의 요청을 읽거나 수정할 수 있는 만큼 매우 번거롭습니다.
    • getReader() 를 앞에서 호출하면 뒤에서 두 번째로 호출해서 에러를 일으킨다던가...
    • 이 부분은 우회할 수 있는 수단이 여럿 있다고 하지만 강의에서는 이상한 방법을 쓰더라구요. ContentCachingRequest 로 래핑을 하고, 요청이 다 처리된 뒤에 요청을 읽는다뇨? 설명도 좀 말이 안 됩니다. 다른 방법도 있다고 하니 차라리 나중에 필요할 때 해보는게 좋겠습니다.
  • 방법은, javax.servlet.Filter 를 구현해서 @Component 로 마킹하면 됩니다.
• Interceptor 구현
  • 컨트롤이 스프링으로 넘어온 뒤에 처리하는 것 같습니다. 그래서 "Spring Context 에 등록" 된다고 표현을 하신듯.
  • "AOP와 비슷한 기능을 한다" 도 같은 의미 같습니다.
  • 로깅보다는 인증용으로 쓰인다네요. 뭐 있을 거 다 있고 요청 거르기도 쉽고...
  • 방법: 인터셉터 인터페이스 구현, WebMvcConfigurator 에서 등록해주면 됩니다. 패키지 스코프 지정도 가능하구요.

그 이후로도 영상강의 자체는 Async 까지 봤는데요, 실습할 시간이 부족하네요.

이번 강의에는 원본의 출처가 대체 어디일지 모를 Spring Web MVC 의 request / response 흐름 다이어그램이 나옵니다. 스프링 공식 문서일줄 알았는데 공식에서 바로 안 나오는 걸로 봐서 제 3자가 그린게 재생산된건지 아니면 예전 버전 그림인건지... 스프링의 구조에 대해 속시원히 해소가 안 되는만큼 언제 시간을 내서 공식 문서를 읽어봐야겠습니다. 서블릿 같은 이상야릇한 스펙들이 겹겹이 쌓인 게 구조나 용어를 복잡하고 이해하기 어렵게 만든 원인 중 하나겠죠.

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.
패스트캠퍼스: https://bit.ly/37BpXiC

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한번에끝내는JavaSpring웹개발마스터초격차패키지Online

아무래도 저는 근간을 이해하고 싶어서, 다음 학습 때에는 못 다한 실습을 마저 하면서 관련된 내용을 좀 더 공부해봐야 할 것 같습니다. 웹이라는 건 근본적으로 request response 쌍을 처리하는 거고, 그걸 위해서 보통 미들웨어라는 개념을 사용합니다. 스프링의 "미들웨어"란 무엇일까요? 왜 그런 구조로 되어있을까요?

다음 시간을 기대하시라(?)