6. The Decorating Filter Pattern

참조
- Foundation of JSP Design Patterns
- http://java.sun.com/j2ee/patterns/DecoratingFilter.html

패턴의 정의

Create pluggable filters to process common services in a standard
manner without requiring changes to core request processing code. The
filters intercept incoming requests and outgoing responses, allowing
pre and post-processing. We are able to add and remove these filters
unobtrusively, without requiring changes to our existing code.

- 필터로 Http request와 response를 인터셉트 하도록 데코레이션하는 패턴

사용처
- 로깅, 사용자의 권한 체크, 데이터 전달, 데이터 검증

Participants & Responsibilities

패턴 적용 전략
- 커스텀 필터 만들기(Dynamic Filter Strategy), 표준 필터 만들기(Declared Filter Strategy)
- 커스텀 필터의 단점
1. 서블릿안에 필터를 하드 코딩해야 한다. -> 변경 사항이 생기면 서브릿을 수정하고 다시 컴파일
2. Request와 Response 객체를 변경할 수 없다. -> 왜냐면 they'll be dispatched upon completion(?)
- 표준 필터 사용의 장점
1. 애플리케이션 코드와 상관없이 필터를 추가, 수정 할 수 있다.
2. 서블릿 컨틀롤러 밖에서 처리하기 때문에 request와 response 객체를 변경할 수 있다.

필터 적용하기
1. 필터 만들기
    - javax.servlet.Fileter 인터페이스 구현
2. web.xml에 선언하기
    - <filter>
          <filter-name>testFilter</fileter-name>
          <filter-class>x.y.foo</filter-class>
       </filter>
3. URL(또는 URL 패턴으) 또는 특정 서블릿에 매핑하기
    - <filter-mapping>
          <filter-name>testFilter</filter-name>
          <url-pattern>/*</url-pattern>
       </filter-mapping>
or
        <filter-mapping>
         <filter-name>testFilter</filter-name>
         <servlet-name>Bar</servlet-name>
      </filter-mapping>
 
생각해볼 것
1. 커스텀 필터의 단점들 중에 두 번째가 잘 이해가 안 됩니다. Request와 Response 객체를 왜 바꿀 수 없는 것인지...
2. Spring 의 HandlerInterceptor(또는 HandlerInterceptorAdapter)는 필터와 같은 역할을 하는데 프로그래밍 방식으로 구현(표준 인터페이스를 따르지 않고 구현)을 하고 사용은 선언적인 방법(web.xml에 선언하지는 않지만 역시 xml에 적용할 url을 설정해줌)으로 사용합니다. 이 경우 필터보다 구현이 간단하고 사용은 선언적인 필터와 거의 유사합니다. 그렇다면 일반적인 필터와 Spring의 인터셉터의 사용처는 어떻게 구분을 할 수 있을까요? 둘 중에 아무거나 편한 것을 사용하면 될까요?
3. (원래는 AOP를 사용하려고 했지만.. 무언가 잘 안되서..)Spring의 인터셉터를 사용하여 간단하게 사용자가 로그인 한 상태인지 아닌지를 확인하는 것을 구현해본적이 있습니다. 이 때 세션에 해당 객체가 있는지 확인하는 방법으로 구현하였습니다. 이 방법보다 보다 더 보편적이거나 유용한 방법이 있는지 궁금합니다.