생각하고 나누고 공감하기...

초인 블로거 Toby님의 친절한 설명 시리즈(1,2,3,4)와 기선님의 설치 및 예제 실행법에 힘입어 저도 자기 전에 (사실 아직 잠을 안 잤으니 자기 전일지 아애 잠을 안 잘지는 잘 모르겠네요) 잠깐 Roo를 맛 봤습니다.

사실 Roo라는 것도 한 달 전 쯤 Toby님에게 우연히 듣게 되었고 몇가지 블로그 글 읽으면서 코끼리 다리 만지듯 이런 저런 상상만 하고 있었는데 이렇게 발표가 되니 반갑기도 하고 당황스럽기도 합니다.

일단 열어 본 첫 인상은 이 Roo가 그 Roo 맞나 싶습니다. 얘기 듣던 것과 구조가 많이 달라서요. 알렉스 아저씨가 지난 3년 동안 발전시킨 생각을 반영해서 원래 Roo와 다른 공개용 Roo를 새로 만든 건 아닌지 모르겠네요. (제가 좀 넘겨 짚기 대왕입니다. -_-);

자세한 것은 Toby님 글을 보면 될 것이고... Toby님 글을 보고 궁금했던 것만 따로 좀 살펴 보았습니다.

우선 Domain에 Repository의 로직을 통합했는데 이건 정확히 Active Record Pattern으로 보입니다. 사실 RoR의 ActiveRecord가 진짜 ActiveRecord는 아닌 것 같다고 생각하고 있었는데... (물론 큰 의미는 없는 구분입니다만) Roo에서 사전적인 구현을 보게 되었네요.

제가 Toby님 글에 답글로 너무 RoR과 비슷하게 만들려고 한 것 아니냐고 쓴 것에 대해 Toby님께서 Roo는 DDD를 구현했다는 점에서 다르다고 하셨는데 DDD가 가능하다는 것은 알겠지만 예제는 자동 생성된 CRUD와 Finder 몇개 외의 DDD의 맛을 볼 수 있는 부분은 아직 없는 듯 합니다. 앞으로 예제가 보완되기를 기대합니다.

다음은 Controller 부분을 봤습니다.

자동 생성된 컨트롤러는 아무런 로직도 없습니다.

@RooWebScaffold(automaticallyMaintainView = true, formBackingObject = PetType.class)
@RequestMapping("/pettype/**")
@Controller
public class PetTypeController {
}

그래서 믹스인되는 AspectJ 파일을 보니 여러가지가 메소드가 정의되어 있네요.

• create() : RequestMapping(value = "pettype", method = RequestMethod.POST) 
  
• createForm() : RequestMapping(value = "pettype/form", method = RequestMethod.GET)
  
• show() : RequestMapping(value = "pettype/{id}", method = RequestMethod.GET)   
  
• list() : RequestMapping(value = "pettype/{id}", method = RequestMethod.GET)   
  
• update() : RequestMapping(method = RequestMethod.PUT)   
  
• updateForm() : RequestMapping(value = "pettype/{id}/form", method = RequestMethod.GET)   
  
• delete() : RequestMapping(value = "pettype/{id}", method = RequestMethod.DELETE)   
  

REST 방식입니다. Parameter가 아닌 PathInfo에서 id를 받고 있는 것도 그렇고 create에 POST, update에 PUT, delete에 DELETE HTTP Method를 사용하는 것도 그렇고 말이죠.
그러니 당연히 spring 3를 쓰고 있다는 거죠.

발표가 안 될 것 같았던 Roo가 Spring 3의 마일스톤 버전이 공개되는 이 시점에 갑자기 발표되는 것이 어떤 의미가 있는 듯 합니다. 마치 개발하기 시작한지 얼마 안 된 것 같은 모습으로 말이죠.

그리고 아직 Presentation 단에는 별다른 기술이 적용되지 않았습니다. 그냥 담백하게 jstl로 갈지, 아니면 다른 생산성 높은 기술이 적용될지 궁금합니다. 저는 웹 어플리케이션의 생산성 향상의 키는 Presentation 단에 있다고 생각합니다. 재사용성을 높이고 변경에 빨리 대응할 수 있는 기술이 적용되기를 기대해봅니다.

가장 감동 받은 부분은 domain에 static method로 믹스인 되는 finder 메소드입니다.
사실 제가 작년에 spring jdbc를 가지고 active record를 구현하려고 시도했었습니다. 한참 진행하다 바쁘고 만들어봤자 쓸 사람도 없고 (회사가 망했습니다. -_-) 해서 그냥 포기했는데요. 그 때 finder를 domain의 static method로 넣고 싶었지만 generic으로는 방법이 없더라고요.

그냥 범용 finder를 만들고 domain class를 parameter로 넘기거나

MyDomain domain = finder.findById(MyDomain.class, 100);

Generic을 사용해서 finder를 domain과 분리하여 따로 만드는 수 밖에 없는 것 같더군요.

MyDomain domain = new Finder<MyDomain>().findById(100);

제가 원하던 방식은 이런 건데 말이죠.

MyDomain domain = MyDomain.findById(100);

그런데 Roo는 AOP로 간단히(?) 구현했네요. 감동이 쓰나미 처럼 몰려옵니다. (다만 Roo의 XXX_Finder.aj에 있는 Finder 메소드들은 Domain 객체를 찾아주지는 않고 JPA Query 객체를 반환합니다. 유연성 때문인지... 반면에 XXX_Entity.aj의 FindXXX 메소드들은 도메인 객체를 직접 읽어서 반환합니다. )

솔직히 지금까지 Mixin이 복잡도를 너무 높이는 것 아니냐는 생각을 가지고 있었습니다. 그런데, 이미 객체지향기술도 한물갔다는 소리가 나오고있는 상황이고... 그동안 트랜젝션 처리나 로깅 정도로만 생각했던 AOP가 어떻게 변화를 줄 수 있는지 실감이 나네요.
 
우짰든 살펴보니 아직 개발 초기단계인 듯 하고 앞으로 계속 주목해야 할 것 같습니다. 완성되면 어떨지 몰라도 아직은 광고처럼 대단해 보이지는 않네요. Toby님 말씀처럼 DDD 대응이라는 점과 Spring을 그대로 사용할 수 있다는 부분이 경쟁 기술에 비해서 나은 점으로 보입니다.

살펴본 것은 30분도 안 되는데 글 쓰느라 한 시간도 넘게 지나갔네요. 글만 쓰면 왜 이렇게 머리 속이 하얘지는 지... 자겠습니다. -_-

서설

스프링 2.5에 새로 추가된 기능 중 예상 외로 인기 있는 기능이 컴포넌트 스캔이다. Classpath를 따라서 탐색 하다가 정해진 필터링 규칙에 맞는 스프링 빈을 찾아 컨테이너에 등록해주는 기능인데 처음 들었을 때 잘 못 쓰면 독이 되겠다 싶었다. Autowiring은 몰라도 최소한 어떤 빈이 사용되는지는 XML에 등록해 주는 것이 관리 하기 좋지 않겠냐는 생각이었다. 빈 등록까지 자동으로 해버리면 애플리케이션 구성을 추적하기 어려워 유지보수가 곤란할 것이기 때문이다. 결국 나는 서비스 계층 후면은 XML을 사용한 전통적인 빈 설정으로, Web Tier는 빈 스캐닝과 Autowiring을 이용하는 방식으로 용처를 정리해서 사용하고 있다.

하지만 내가 결정권이 없는 여러 프로젝트에서 빈 스캐닝 기능을 사용하는 일이 많은 것이 현실이다. 그리고 절대 저질러서는 안 되는 범죄도 아니고 대부분 그리 복잡한 애플리케이션도 아니니 잘못 되었다고 말할 것도 아니다. 결국 두어 번 이런 상황에서 일을 하게 되었다. (사실 XML로 설정을 한다고 해도 관리가 허술하면 복잡하기는 마찮가지다. 설정 관리자라는 롤이라도 두어야 하는 걸까?)

이런 저런 것 떠나서 빈 스캔 기능을 사용하면 가장 곤란한 것이 특정 값을 빈에 설정할 수 없다는 것이다. 스프링은 단순히 빈 간의 종속성 문제만 해결해줄 뿐 아니라 빈의 초기 상태를 설정할 수도 있다. 그런데 XML이 아닌 방법으로 스프링에 의존하지 않고 POJO의 순수성을 유지한채 특정 값을 설정하는 방법이 마땅치 않다. (적어도 내 지식으로는 그렇다.)

애노테이션 환경에서 Property 값 설정

PropertyInjectionConfigurer는 스프링의 PropertyPlaceholderConfigurer나 PropertyOverrideConfigurer와 비슷한 기능을 한다. 즉, 빈 초기화 단계에서 지정된 Property 파일의 값을 특정 빈의 필드에 넣거나 특정 메소드를 이 값을 가지고 호출한다. 다만 XML 설정이 아닌 애노테이션 방식을 사용한다는 것이 다르다. @Property 애노테이션을 Property 값을 받기 원하는 필드나 메소드에는 달아 놓으면 PropertyInjectionConfigurer가 빈 초기화 단계에 이 애노테이션을 인식해서 원하는 값을 찾아 설정을 해준다.

물론 지금 1.0 M4 상태인 Spring JavaConfig나 1.0 M3 상태인 스프링 3가 정식 발표 된다면 문제가 안 되는 부분일 수 있다. 그러니 스프링 2.5만을 사용하고 JavaConfig를 기다릴 수 없는 (또는 JavaConfig를 사용 안 할) 프로젝트에만 사용하면 될 듯 하다. 그리고 JavaConfig의 @ExternalValue가 맘에 안 드는 사람도 있을 듯 하다.

파일 다운로드

property_injection.tar.gz

소스 파일을 이클립스에서 Java 프로젝트(Spring IDE plugins가 설치되어 있으면 spring project)로 Import해서 열면 바로 사용이 가능하다. 일단 처음에는 테스트가 있으니 작동 유무를 이를 통해서 확인 한다.

기존에 프로젝트 코드 베이스에 포함되어 있던 클래스 하나만 분리해서 만든 프로젝트이니 굳이 jar로 만들어 쓰기 보다는 그냥 사용할 프로젝트의 코드 베이스에 복사해서 패키지를 적절하게 변경한 다음에 사용하는 것이 좋을 듯 하다.

설정

가장 먼저 PropertyInjectionConfigurer를 XML에 등록한다.

    <bean class="property_injection.PropertyInjectionConfigurer">
        <property name="location" value="property_injection/test.properties"/>
    </bean>

location 속성에 설정 값이 등록되어 있는 propertis 파일의 경로를 지정한다. 만약 properties 파일이 여러개라면 이렇게 할 수도 있다.

    <bean class="property_injection.PropertyInjectionConfigurer">
        <property name="locations">
            <list>
                <value>classpath:property_injection/test.properties</value>
                <value>classpath:property_injection/another.properties</value>
            </list>
        </property>
    </bean>

물론 간단히 직접 Properties 값을 주는 것도 가능하다.

    <bean class="property_injection.PropertyInjectionConfigurer">
        <property name="properties">
            <value>
                mail.server=mail.domain.net
                mail.sender=admin@domain.net
            </value>
       </property>
    </bean>

설정 방법은 PropertyPlaceholderConfigurer와 같으니 레퍼런스를 참조하도록 한다.

필드에 @Property 사용

일단 PropertyInjectionConfigurer를 등록했으면 Property 값을 지정하고 싶은 필드나 메소드에 @Property 애노테이션을 표기해야 한다. 직접 필드에 값을 지정하도록 할 수 있다.

    @Property(name="mail.server")
    private String mailServer;

메소드에 @Property 사용

메서드에 @Property를 달아 놓으면 초기화 단계에 해당 메소드를 호출한다. 이 메소드는 매개 변수가 하나 이상이어야 한다.
   
    @Property(name="mail.server")
    public void setMailServer(String mailServer) {
        this.mailServer = mailServer;
    }

필수가 아닌 Property

만약 지정한 Property 값을 찾지 못하면 예외를 발생시키기 때문에 빈 생성을 하지 못하게 된다. Property 값이 있어도 되고 없어도 되는 값이라면 required 속성를 false 값으로 바꾸어 예외 발생 없이 넘어가도록 할 수 있다.

  @Property(name="property.name" required=false)

required 속성을 사용할 때에는 기본값을 필드에 지정하는 것이 좋을 것이다.

  @Property(name="mail.server" required=false)
  private String mailServer = "default.mailserver.com";

스프링을 알고 나서 사용하는 즐거움 외에 부수적인 즐거움 몇 가지가 있는데 그 중 큰  것은 멋진 소스코드와 설계 노하우를 접할 수 있다는 것과 정말 마음에 드는 기술 문서를 알게 되었다는 것 입니다.

지금까지 많은 기술 문서를 접했지만 스프링 레퍼런스는 정말 읽기 쉽고 원하는 내용을 찾기 쉽게 작성되어 있습니다. 무엇보다 점진적인 학습이 가능합니다.

스프링은 전부 다 몰라서 아는 만큼만 써도 유용하게 쓸 수 있는 프레임워크라고 생각합니다. 그 후에 익숙해져서 더 배우게 되면 그만큼 더 활용할 수 있는... 꺼내도 꺼내도 끝이 없는 화수분 같은 프레임워크입니다. 그리고 레퍼런스도 그렇게 작성되어 있습니다.

그래서 앞으로 저도 프로그램을 만들게 되면 스프링 같이 만들고 레퍼런스를 작성할 때에는 스프링 레퍼런스 처럼 작성하고 싶다는 생각을 하고 있습니다.

좌우간 지금까지는 쓸데 없는 얘기였고... (졸려요. =.=) 이번에 KSUG에서 스프링 레퍼런스를 한글로 공동 번역하는 작업을 진행하기로 했습니다. 시간도 없고 영어 실력도 미천하여 별 도움은 못 되겠지만 늘 받아 먹기만 하는 것이 미안하여 (그리고 공부도 좀 할 요량으로) 참가를 하게 되었습니다.

여러 논의 끝에 HTML로 작업하기로 했는데 정작 스프링 배포본의 HTML 파일은 사람이 작성한 것이 아니고 docbook으로 만든 원본문서를 XSL로 변환해서 자동 생성한 것이라서 아주 지저분하더군요. 버스에서 퇴근하면서 노트북으로 번역을 하고 있기 때문에 마우스질이 힘든데 영 작업이 어렵더라고요.

그래서 그냥 docbook으로 작업을 하고 HTML로 변환한 후에 제출하기로 했습니다.

우선 스프링 CVS에서 레퍼런스 소스를 내려 받고 문서를 빌드하는데 필요한 몇가지 파일을 추가했습니다. spring ant 빌드 파일에서 레퍼런스 빌드 부분만 빼서 빌드 파일도 만들었고요.

한글 문제도 있어서 인코딩을 UTF-8로 되도록 약간 수정했습니다. 아직 PDF는 폰트 설정을 안해서 한글이 안 되지만 HTML 변환은 잘 되네요.

혹시 저 처럼 스프링 레퍼런스 같은 문서를 docbook으로 작성하고 싶으신 분들을 위해서 올려 놓습니다.

저는 아마테라스에서 작업하지만 ant 만 설치되어 있다면 vi나 editplus 같은 일반 에디터로 작업하셔도 됩니다.

나중에 PDF 변환도 한글이 되도록해서 다시 올려 놓겠습니다.

spring_reference.zip