1.0 M4상태에 머물고 있던 JavaConfig이 스프링 3.0 M3의 시작과 함께 스프링코어프레임워크에 통합되었다. S1A에서의 발표는, JavaConfig의 핵심기능만 통합하는 것이었다. JavaConfig자체는 별도의 설정 옵션으로 독립적으로 발전시킨다는 것이었고.
언제나 그렇듯이 스프링의 변신은 스프링이 어디로 튈지 모르는 것처럼 예측 불가능이다. JavaConfig은 M4이후 사실상 개발이 중단된 상태다. 발표된 예정대로라면 3월이면 이미 RC버전이 나오고 1.0으로 향하고 있어야 하겠지만, 개발자인 Chris Beams는 코어의 confg.java 모듈작업에 열중이다. 어엇. 그런데 M3 초기에 통합되었던 config.java 모듈이 보이지 않는다. 어디로 간 것일까?
org.springframework.config.java 모듈은 사라졌다. JavaConfig은 더 이상 옵셔널 모듈이 아닌 스프링의 context 모듈의 핵심으로 완전히 융합되어버렸다. config.java모듈이 간 곳은 context모듈의 context.annotation이다. 그래서 이제 JavaConfig이라는 존재는 사라지고 annotation방식의 application context 기능으로 변신한 것이다.
애노테이션 자체도 바뀌었다. 기존에 @Beans와 @Bean 애노테이션은 각각 <beans>와 <bean>에 대응되는 개념이었다. JavaConfig설정 자체가 하나의 부트스트래핑의 수단이었다면, 이제는 스프링의 context의 흐름에 완전히 흡수되었다.그래서 @Bean는 사라지고 @Configuration이라는 개념이 도입도었으며, JavaConfigApplicationContext가 아니고 AnnotationConfigBeanDefinition이라는 개념으로 바뀌었다.
BeanDefinition이라 하면 2.0에서 schema기반의 xml설정을 지원하기 위해서 자주 보던 바로 그 스프링 빈의 메타 정보이다. 이제 JavaConfig에서 사용되던 @Beans 클래스는, @Configuration 클래스가 되어서 BeanDefinition의 한가지 모델로 추가된다. 이렇게 추가된 정보는 ConfigurationClassPostProcessor라는 BeanFactoryPostProcessor에 의해서 빈으로 변신한다.
이는 마치 xml <bean>에 대해서 @Component라는 애노테이션 정의가 등장했듯이, xml schema에 대해서 @Configuration이 대응되는 개념으로 등장한 것이라고 볼 수도 있다. 기존에 생각했던 JavaConfig의 개념이 세단계쯤 업그레이드 된 느낌이다.
더욱 재밌는 것은 @Configuration은 scanner를 통해서 감지될 수 있다는 것이다. 더군다나 @Configuration 자체가 @Autowired등에 의해서 DI될 수 있다는 것이다. XML에서는 상상하지 못했던 완전히 새로운 개념이다. 자바클래스로 만들어진 설정이기 때문에, 마치 DI의 대상인 Bean처럼 동작할 수도 있다는 개념이다. 그래서 나는 이것을 빈처럼 설정가능한 빈 설정이라는 개념으로 메타 빈(meta-bean)이라고 부르고 싶다. 이러다가 빈과 같은 빈 설정의 빈과 같은 설정의 빈과 같은 설정의.. 이렇게 갈지도 모르겠다. BeanDefinition 아키텍처의 컨셉을 생각해보면, 불가능할 것도 아니다.
이렇게 변신한 JavaConfig은 2.5의 설정기능을 뛰어넘어 더욱 강력하게 DI의 모든 설정을 지원하려고 하고 있는 @DI와 더불어, 3.0의 @DI/IoC 기술을 그 어떤 DI기술보다 월등히 뛰어나게 만들어 주지 않을까 기대된다. 아직은 테스트 코드에도 BeanDefinition과 ConfigurationClassPostProcessor을 직접 사용해야 @Configuration을 쓸 수 있으니, 변신한 JavaConfig을 제대로 경험해보기는 불편하다. 스프링 코어 개발에 가장 늦게 참여했지만, 가장 활발한 활동을 보이고 있는 Chris Beams의 활약을 계속 지켜봐야 할 것 같다.
아직 3.0의 진가는 다 드러나지 않았다. 계속 기대하시라.
Related posts:
- Spring 3.0 (56) @Bean 사용의 주의사항
- S1A 2008 셋째날 – Spring JavaConfig
- InsideSpring (1) Annotated Factory Method (@Configuration)을 쓰는 4가지 방법 (1)
- Inside Spring (5) PropertyPlaceholderConfigurer를 @Bean으로 정의해서는 안되는 이유
- Spring 3.0 (54) 드디어 등장한 ConfigurationClassApplicationContext
- Spring 2.0의 XML확장기능 (1)
- InsideSpring (1) Annotated Factory Method (@Configuration)을 쓰는 4가지 방법 (3)
- Spring 3.0 (30) R-723 JavaConfig 통합
- Spring 3.0 (24) 3.0 M2 공개 이틀전
- Spring 3.0 (60) 클래스패스 리소스를 지정할 때 주의사항과 팁
- Spring 3.0 (14) Context Support 모듈의 선택 라이브러리 분석
- Spring 3.0 (1) 프로젝트 구조와 빌드 시스템의 변화
- Spring 3.0 EL (Spel)을 이용한 AssertThrows 확장 (1)
- Spring 3.0 (32) R-778 돌아온 Reference Doucment와 잠자는 레퍼런스 한글화 프로젝트
- Spring 3.0 (13) Context 모듈의 선택 라이브러리 분석
메타빈이 뭔가 했더니 그런 거였군요. 흠..
저는 “빈 설정을 담고 있는 빈”이니까 메타빈 보다는 설정빈이 낮지 않을까요? Configuration Bean~