어제 12시쯤에 잠들었는데 3시에 그만 깨고 말았다. 다시 잠들려는 찰라에 부스럭 거리면서 일어나 돌아다니는 기선이 때문에 다시 잠들기회를 놓쳤다. 이런! 잠은 안오고 멀뚱히 있기 뭐해서 이런 저런 일을 하다가 결국 심심해서 4시에 광남이 형과 영회를 깨워서 불러서 함께 놀기 시작했다. 셋째날은 이렇게 일찍 시작 되었다.

모이면 맨날 하는 얘기.. 광남이 형의 OKJSP를 OKSpring으로 바꾸거나, OK Java SPring으로 바꾸자는 것. 이번 기회에 완벽한 스프링빠로 만들어야 할텐데… 만나는 외국 스프링 개발자들마다 OKJSP 사이트를 홍보하며 "JSP 걱정없다 OK!"를 외치는 형의 모습을 보니 OKJSP가 어떻게 한국최고의 자바 커뮤니티로 성장했는지를 알 수 있을 것 같다.

 

일어난지 5시간 만에 아침을 듬뿍 먹고 이제 셋째날 첫째 세션 실시간 포스팅 시작.

JavaConfig은 꽤 오랜동안 milestone 상태로 머물러있는 프로젝트였다. 3.0에는 core에 병합이 된다고 하니 기대할만하다.

  • JavaConfig은 <bean/> 을 @Bean으로 대체하자는 것.
  • Type-safety를 원하고, pure Java(refactorable)로 작업하는 것을 선호한다면 JavaConfig
  • DI container의 full power를 제공한다.

IDE와 XML namespace 등의 도움으로 spring xml config.은 상당히 편해졌다.  하지만 몇가지 문제를 남겼는데..

  • String 기반이라는 문제가 그 대표적인 것이다. String은 리팩토링에 적합하지 않다.
  • XML에서 가져오는 getBean()은 casting의 부담도 있다.

JavaConfig은 Java5+의 장점을 최대한 활용할 수 있고, string에서 벗어나게 해준다. (Generics, @nnotations)

  • <bean ..class="ClassName"> ===> @Bean ClassName method() {…}
  • <bean/>은 @bean에 그대로 매핑될 수 있다.
  • <beans />는 @Configuration으로 대체가능하다. 오호!
    • beans는 class레벨로, bean은 method레벨로 정의할 수 있다.
    • method의 이름이 bean id가 된다.

Bootstrap : JavaConfigApplicationContext

@Configuration

public class AppConfig {

  public @Bean FooService fooService() {

    return new FooService();

}

각종 annotation, component scan, aspect 설정들을 모두 JavaConfig을 통해서 처리하는 것이 가능하다.

XML을 JavaConfig으로 import 할 수도 있다. 점진적으로 JavaConfig으로 변환도 가능하다.

JavaConfig과 XML은 거의 완벽하게 상호변환이 가능하다. JavaConfig이 더 type-safe 하다는 것만 빼고.

앞으로 자체 namespace 지원기능도 추가될 예정이다.

 

여러개의 @Configuration 클래스에 @Bean이 나뉘어 있고, 상호참조를 한다면? 이때는 JavaConfig 자체에 @DI를 적용할 수 있다. 즉 @Autowired로 다른 @Bean설정을 DI해서 사용하는 것이 가능하다. DI의 DI로구만.

이렇게 설정한 JavaConfig은 거의 완벽하게 refactorable하다. 또 IDE를 통해서 navigation하는 것이 매우 편리하다.

@Import를 사용하면 import되는 클래스에는 @Configuration등의 설정이 필요없고, import시키는 쪽 클래스의 설정에 따르게 된다. XML의 import와 개념이 비슷하다.

 

WebApp은 어떻게?

일반적인 접근방법은 web.xml에 listener로 ContextLoaderListener를 정의해서 xml을 로딩한다.

ContextConfig에 옵션을 하나주어서 xml 대신 JavaConfig class를 사용하도록 재정의할 수 있다.

 

JavaConfig의 장점은 xml 작성보다는 IDE의 편리한 지원을 받아 자바코드를 작성하는 것이 더 편리하고 직관적이라는 것이다. 당연히 type-safe하며, 리팩토링이 완벽하게 지원된다는 것이 가장 큰 장점. 또한 DI나 각종 빈의 생성도 자바코드로 원하는 대로 유연하게 작성할 수 있다는 장점도 있다. 또 설정을 모듈화 하기도 편리하고.

단점으로는 아무래도 설정이 많아지면 자바코드가 많아지고 xml보다는 가독성이 좀 떨어질 것이다. 하지만 @autowired, @component 스타일의 스캔을 사용한다면 또 설정자체가 많지 않으니 별 문제가 되지 않을 수도.

이제 본격적으로 xml, annotation, java 세가지 방식의 스프링 설정이 경쟁적으로 사용되어질 때가 된듯 하다. 스프링소스에서 공개한 것은 아니지만, ruby로 설정하는 것도 있다고 하니.. 스프링설정의 유연함은 점점 더 늘어간다. 하지만 best practice와 선택의 고민이라는 문제를 던져주기도 한다. 행복한 고민일 듯.

 

PetClinic을 JavaConfig으로 변환하는 데모를 끝내고 이제 roadmap.

M5가 거의 Spring3.0과 비슷하게 등장. Spring3.0에 JavaConfig의 core가 삽입. Spring 3.0 릴리즈 직후에 1.0GA 릴리즈 목표다. 언제나 목표는 목표, 계획은 계획이니깐. 어쨌든 Spring3.0에 삽입된다는 것이 가장 중요한 결정인듯. 근데 core만 들어간다고 하는데 core가 아닌 것들은 어떻게 구분되는 것일까?

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha