Toby's Epril

스프링 3.0에서 코어에 통합된 자바콘픽(@Configuration)은 여러모로 매력적이다. 하지만 그게 왜 매력적인지 느끼기는 쉽지 않다.

일반 개발자들이라면 애플리케이션 빈은 @Component로 스캔해서 만들면 그만이다. 트랜잭션, AOP, 유틸 따위의 인프라 빈은 XML의 <namespace:*>을 이용하면 간편하게 등록하고 설정할 수 있다.

반면 <tx:*>나 <aop:*> 등을 자바코드로 빈을 만들어서 등록하라고 하면 막막하다. @Transactional이 적용되게 하려면 <tx:annotation-driven />을 XML에 넣어주기만 하면 되는데, 이걸 @Cofiguration 클래스의 @Bean메소드로 직접 관련된 빈을 만들려면 어떤 빈 클래스를 어떻게 만들고 설정해야 할지 알 수 없기 때문이다. 스프링 소스를 파보기 전에는 파악하기도 불가능하고, 소스를 본다고 해도 스프링 소스중에서도 가장 난해한 NamespaceHandler류와 BeanDefinitionParser는 해석하려면 상당한 노력이 필요하다. 혹시 자신있으면 ConfigBeanDefinitionParser따위를 한번 들여다 보고 어떤 경우+옵션에 어떤 빈이 어떤 설정으로 만들어지는지 파악해보든가.

그래서 임의의 자바코드를 이용한 빈 등록과 설정 방식을 지원하고, 자동 빈 스캔을 이용할 수 있는 3.0에서도 설정용 XML은 반드시 필요했다.

하지만 스프링 3.0에서는 XML의 전용 설정 태그를 대체할 수 있는 @Enable류의 자바콘픽 설정방식이 등장했다. 그래서 XML없이도 간편하고, 타입체크도 쉬우면서, 훨씬 유연한 방법으로 각종 인프라 빈의 등록과 설정이 가능해졌다. 원하면 스프링관련 XML을 모두 제거하는 것도 가능하다.

XML 몇줄 들어가는 것이 무슨 상관이냐, 스키마도 있어서 IDE에서 자동완성과 타입체크도 된는데라고 생각한다면 그냥 XML 써도 그만이겠지만. 새로운 설정방식에 관심이 있다면 @Enable로 대표되는 자바코드 설정 방식에 도전해보는 것도 좋겠다.

XML을 쓸 때 빈의 종류에 따라서 XML파일을 분리해서 사용하는 경우는 흔치 않다. 기껏해야 웹 관련 여부에 따라서 루트 컨텍스트와 웹 컨텍스트 정도를 구분하는 수준이다. 반면에 자바코드를 이용하면 성격에 맞게 각각의 설정을 독립된 @Configuration 클래스에 분리하는 것이 간편하고, 깔끔하게 보일 수 있다.

예를 들면, <tx:*>류에 대응되는 @EnableTransactionManagement가 붙은 클래스라면 관련된 DataSource나 SessionFactory 빈 등만 넣어두면 깔끔하다. 이러면 설정 클래스를 조합해서 재사용하기도 쉬고, 코드도 직관적이고, 테스트할 때도 원하는 설정 클래스만 모아서 돌리면, 애플리케이션 전체 인프라 빈을 다 가동시키지 않아도 되기 때문에 빠른 실행이 가능하다.

@Enable~류의 가장 큰 매력은 단순히 애노테이션 엘리먼트를 통한 설정만 가능한게 아니라, WebMvcConfigurer와 같은 discoverable config. API를 이용해서 좀더 복잡한 설정이 가능하다는 점이다. 대표적인 것이 3.0에서 가장 어정쩡했던 <mvc:*>를 대체할 수 있는 @EnableWebMvc와 WebMvcConfigurer이다. 종류도 많고 설정 방식도 복잡한 DispatcherServlet의 전략을 <mvc:*>로 꾸미면 상당히 지저분한데,  이를 자바코드만으로 편리하게 만들 수 있다.

@Enable~이 가지는 또 다른 매력은, XML 네임스페이스 활용방법이 그랬던 것처럼, 개발자가 프로젝트에 필요한 인프라 빈 또는 앱 빈을 간결한 방식으로 등록, 설정 가능하도록 직접 활용할 수 있다는 점이다. 만들기 까다로운 스키마-전용태그-빈정의파서 등등 방식보다 훨씬 쉽고 편하게 개발가능하다.

프로젝트에 적용한 사내 프레임워크의 기본 설정등을 @Enable 애노테이션과 엘리먼트 값 정도만 가지고 한방에 설정하도록 하는 것도 가능하다. 예를 들어 @EnbaleHibernate 라는 것을 하나 만들어서, database.properties 정보를 활용해서 DataSource를 만들고, SessionFactory도 만들고, 트랜잭션 AOP도 걸고, 기타 관련 빈 등을 한방에 세팅할 수 있도록 만들 수 있다. 몇가지 @Enable~을 조합하는 것만으로 사내 표준 프레임워크의 인프라 빈을 모두 세팅하는 것도 괜찮은 방법일테다. 매번 샘플에 나온 스픠링 XML을 카피카피 해서 조금씩 고쳐쓰다가, 깜빡하고 한줄 잘못 지워서 엉뚱하게 동작하는 따위를 막아줄 수도 있을테고.

다음 번엔 @Enable~등을 어떻게 만들 수 있는지, 스프링 3.1이 제공하고 실제로 적용한 방식이 무엇인지 정리해보자.

그리고 지금은 구상단계긴한데, 1월 2~3째주쯤에 이에 대해서 관심있는 분들과 함께 흥미로운 세미나를 할까도 생각중이다.

사실 3.1 얘기를 인터셉터로 시작하려고 했던 것은 아니다. 지난 포스팅의 핵심은 자바콘픽의 사용방법이었고, @MVC 콘픽 클래스에서 인터셉터를 적용하는 메소드의 예를 든 것은 문제가 생겼을 때 난처한 결과를 맞을 수 있는 적절한 예이기 때문이다. 자세한 설명은 내년중에 마무리할 토비의 스프링 3 개정판에서 다루겠지만, 그래도 눈치를 채고 문제를 짚어낼 분이 있을까 싶어서 질문으로 마무리해본 것인데, 대부분 별 관심이 없는듯하고, 몇몇분은 그냥 답 내놓으라고만 하니…

유일하게 SuHong Lee님이 성의있는 의견을 주셨다.

혹시 인터셉터의 적용 순서를 알 수 없다는 것에대한 문제 인가요??
정확히는 모르겠네요
<mvc:>를 사용 하면 적용 순서를 알 수가 있을텐데
위와 같이 적용하면 순서가 어떻게 적용 될지 모를 수도 있을 듯하네요

스프링에는 Ordered 인터페이스를 구현하고 order프로퍼티를 노출시켜서 적용 순서를 지정할 수 있도록 만들어진 빈들이 제법 많다. 자주 눈에 띄는 것을 꼽자면 HandlerMapping류 빈들이 있다. 여러 핸들러매핑 전략을 동시에 적용할 때, 우선순위를 지정해서 가장 먼저 걸리는 핸들러를 적용하도록 만들 수 있다. 일부 뷰리졸버도 그렇고.

하지만 MVC 인터셉터의 API인 HandlerInterceptor나 그 구현 빈들은 Ordered가 적용되어있지 않다. 따라서 숫자값을 설정해서 그걸로 인터셉터의 적용 순서를 결정하지도 않는다.

인터셉터는 핸들러매핑 안에서 만들어지는 핸들러 호출용 HandlerExecutionChain안에 핸들러(컨트롤러라고도 부르는)와 함께 들어가서 실행체인의 일부로 만들어진다. 이렇게 만들어진 핸들러 체인은 DispatcherServlet에 의해서 적절한 순서에 의해서 인터셉터와 핸들러가 실행된다.

여러개의 인터셉터가 적용됐을 때, 각각이 독립적이고 서로 간섭이 없다면(핸들러체인 실행을 중단하는 따위) 실행 순서가 어떻게 되든 상관없다.  반면에 실행순서가 의미가 있는 경우라면 일정한 실행 순서가 보장이 되야 한다. HandlerInterceptor는 pre와 post가 반대의 반향으로 실행된다. 인터셉터 1,2,3이 있고, 1,2,3의 순서가 정해져있다면 1-2-3-handler-3-2-1-view-3-2-1의 순서로 실행될 것이다.

그럼 실행 순서는 어떻게 결정되는가?

일단 3.1얘기니까 3.1의 핵심인 WebMvcConfigurationSupport이나 WebMvcConfigurer를 사용했다고 보면, addInterceptors() 메소드를 구현 또는 오버라이딩하고, 파라미터로 전달된 InterceptorRegistry를 이용해서 인터셉터를 추가해주면 된다. 3.0에서 등장한 <mvc:interceptors>를 이용한 방법과 거의 동일하다.

InterceptorRegistry는 HandlerInterceptor 타입의 인터셉터와 WebRequestInterceptor 타입의 인터셉트 두 가지를 등록할 수 있게 되어있다. 일반적으로 HandlerInterceptor가 인터셉터를 만들 때 쓰는 대표적인 인터페이스지만, HandlerInterceptor는 Servlet API에 종속적이라는 단점이 있기 때문에, Portlet을 본격적으로 지원(원래 1.3에 들어가기로 한 기능인데, S1 2005인가 하면서 1.3을 건너뛰고 2.0으로 가기로 결정 했고, 그래서 2.0에 뒤늦게 등장했다)기 시작한 2.0부터는 웹 기술 API에 독립적인 WebRequestInterceptor가 등장해서 HandlerInterceptor와 함께 사용되기 시작했다. 서블릿 환경에서만 사용할 것이라면 HandlerInterceptor로 충분하겠지만, 서블릿, 포트릿 환경에 가릴 것 없이 사용될 수 있다면 WebRequestInterceptor가 적합하다. 그래서 지난번에 예로 들었던 OSIV인터셉터도 WebRequestInterceptor를 구현하고 있다.

이렇게 두가지 종류의 인터셉터가 섞여서 등록된다면 그 실행 순서는 어떻게 될까?

기본적으로는 인터셉터의 구현 방식은 순서에 영향을 주지 않는다. 실행순서는 레지스트리에 등록한 순서다. 내부에서 List로 저장해서 관리하기 때문에 순서가 보장된다. WebRequestInterceptor도 결국 실행 환경을 보고 적절한 아답터(WebRequestHandlerInterceptorAdapter 같은)를 통해서 HandlerInterceptor 타입으로 전환되서 실행체인으로 넘어가므로 사실 구분이 없다. 스프링(정확히는 Spring-mvc 모듈)은 내부적으로 이런 인터페이스들을 adapted interceptor라고 부른다.

그러면 그냥 인터셉터는 InterceptorRegistry에 add한 순서라고 보면 될까?

그런데, 그게 또 아니다.

인터셉터는 또 다시 단순 adapted interceptor와 mapped interceptor로 구분될 수 있다. 후자도 결국은 같은 HandlerInterceptor를 구현한 인터셉터지만 특정 URL패턴에 매칭되는 경우에만 실행되는 놈이다. <mvc:>를 썼다면 <mvc:mapping path="/secure/**"/>과 같이 사용했던 바로 그 방식이다.

그런데, 이렇게 매핑패턴을 가지는 mapped interceptor는 일반 인터셉터보다 실행 우선순위가 밀린다. 레지스트리 등록순서에 상관없이 나중에 실행된다.

정리하자면, 인터셉터는 단순 인터셉터(adapted interceptor)가 먼저 실행되고 매핑 인터셉터(mapped interceptor)가 그 다음에 실행되는데, 종류별로는 인터셉터 레지스트리에 등록된 순서대로 실행이 된다.  따라서 아무리 mapped interceptor를 먼저 등록해도 나중에 실행될 것으로 판단해야 한다.

만약 URL매핑을 하는 인터셉터가 우선적으로 실행되게 만들고 싶다면? 그때는 HandlerInterceptor를 구현해서, 거기서 URL비교를 해서 인터셉터 로직을 적용할지 말지를 결정하도록 만들고 URL패턴 없이 일반 인터셉터로 등록해서 사용하면 될 듯.

일단 여기까지.