[TIL] 230710 Filter, 왜 HttpServletRequest 으로 캐스팅할까?

CountryGirl·2023년 7월 10일
0

TIL

목록 보기
18/80

📌 Filter

Web 애플리케이션에서 관리되는 영역으로 클라이언트로부터 오는 요청과 응답에 대해 최초, 최종 단계에 위치이며 요청과 응답의 어떤 정보를 변경하거나 부가적인 기능을 추가할 수 있다.
(**주로 범용적으로 처리하는 작업들... Logging.. or.. 보안처리.. or..인증 & 인가)

필터는 하나만 있는게 아니라 체인(Chain) 형식으로 여러 개가 묶여서 처리된다.
➡️ (FilterChain)

여러 개가 묶여서 처리되므로 처리되는 순서를 정해야한다.

@Order(1)		// #1 첫번째 Filter
@Order(2)		// #2 두번째 Filter
@Order(3)		// #3 세번째 Filter

클래스 위에 @Order(#) Annotation 을 달아서 순서를 정해준다.

📌 궁금한 점

Logging Filter 예시 코드를 보다가 의문이 들었었다.

public class LoggingFilter implements Filter {
    @Override
    public void doFilter(
            ServletRequest request, 
            ServletResponse response, 
            FilterChain chain
    ) throws IOException, ServletException {
        
        // 전처리
        HttpServletRequest httpServletRequest = (HttpServletRequest) request;
        String url = httpServletRequest.getRequestURI();
        log.info(url);

        chain.doFilter(request, response); // 다음 Filter 로 이동

        // 후처리
        log.info("비즈니스 로직 완료");
    }
}

이 코드에서
HttpServletRequest httpServletRequest = (HttpServletRequest) request; 이 부분을 보면 ServletRequest를 HttpServletRequest로 캐스팅을 한다.

맨처음부터 파라미터로 HttpServletRequest를 받았으면 굳이 캐스팅을 할 필요가 없지 않을까?

그래서 파라미터를 ServletRequest 대신 httpServletRequest로 바꾸어보았다.

public class LoggingFilter implements Filter {
    @Override
    public void doFilter(
            HttpServletRequest request,
            HttpServletRequest response,
            FilterChain chain
    ) throws IOException, ServletException {

        // 전처리
        String url = request.getRequestURI();
        log.info(url);
        ...
        ...
    }
}

그러자 public class LoggingFilter implements Filter@Override 부분에서 오류가 났다.
이유를 보니 Filterimplements 해서 LoggingFilter를 만들었고, doFilter()Filter interface의 메서드였고, 그 메서드를 @Override 하고 있었기 때문이었다.

profile
💻🌾시골소녀의 엉망징창 개발 성장일지🌾💻 (2023.05.23 ~)

0개의 댓글