참고로, 영문자료 모음은 http://forum.springsource.org/showthread.php?t=71985 에 있습니다.

Max님 : http://yunsunghan.tistory.com/tag/ROO

Spring ROO A1 테스트 하기

Spring ROO A2 Member 도메인 테스트 하기

Spring ROO 파일구성 보기

Spring ROO shell 명령 테스트 하기

Spring Roo 스크립트 활용하기

Spring ROO 와 DDP 구조 합성에 대한 기대

Spring Roo 잡소식

Spring Roo ITDs의 가독성

Roo addon-web-mvc-jsp

Roo를 바라보는 시선

Spring Roo 잡소식(2)

Roo - @RooWebScaffoldMetadata

Roo - Finder.aj 생성하기

Spring Roo 최신 버전 빌드하기

Spirng Roo dateFormat 옵션 추가 됨

Spring Roo 아키텍처 도식

Spring Roo 잡소식(3)

Spring Roo 잡소식(4)

Roo addon-web-mvc-jsp

Spring Roo RC2[Revision 319] Demo Testing

Spring Roo 잡소식(5)

Spring Roo 잡소식(6)

Spring Roo 잡소식(7)

Spring Roo 잡소식(8)

Spring Roo 프로젝트 진행 후기

Toby님

Spring ROO 대충대충 분석 (1) 공개과정

Spring ROO 대충대충 분석 (2) ROO란 무엇인가?

Spring ROO 대충대충 분석 (3) ROO의 Inter-type declaration

Spring ROO 대충대충 분석 (4) ROO의 미래와 의의

테스트 할 수 없는 것을 테스트 하기. Spring ROO와 static method mocking.

Whiteship(백기선)님

Roo 설치하기

스프링 Roo petclic 예제 실행 성공

박성철님

자기 전에 잠깐 살펴본 Spring Roo

자바지기(박재성)님

Spring Roo를 적용하면서 느끼는 점

  Apache FTP 서버(http://mina.apache.org/ftpserver/ )는  Java기반의 오픈소스 FTP서버입니다.

  Java기반의 모듈이라고 하면 성능이 안 나오지 않을까 걱정하시는 분도 계실 것 같습니다. 이전에 1.0.M3버전으로 제 PC에서 다른 FTP서버와 비교해서 테스트해본 결과는 아래와 같았습니다.

• 테스트 환경

  • OS : Windows XP
  • CPU : Intel® Core™ 2 Duo CPU E6750, 2.66GHz
  • RAM : 2GB

• 업로드 테스트 데이터
  

  • 용량 : 126MB
  • 파일수 : 392개
  • 폴더 : 16개

   테스트 결과로 윈도우에서 돌아가는 다른 FTP서버와 비교했을 때 가장 빠른 속도를 보여주는 예상밖의 성능이 나왔었습니다. Linux등에서는 어떤지 몰라도 크게 성능을 걱정할 수준은 아닐 것으로 예상됩니다.

  Apache Ftp서버는 설정만으로도 FTP에 부가적인 기능을 많이 사용할 수 있습니다.  예를 들면 Log4j의 설정을 이용해서 원하는 수준과 방식으로 로그를 기록할 수 있고, 사용자정보를  입력,조회 등의 쿼리만 설정 파일에 넣어주면  DB로 사용자를 관리할 수 있게도 해줍니다.

  그리고 Java기반이다 보니,  직접 코딩을 해서 확장을 하는 것도 손쉽습니다. Apache FTP 서버에서 정의한 인터페이스대로 코딩을 하고 이를 설정파일에다 추가할 수도 있죠. 대표적으로 Ftplet과 같은 인터페이스가 있습니다.

 활 용사례로,  Hadoop의 파일시스템인 HDFS(Hadoop Distributed File System)으로 파일을 올릴 수 있는 서버모듈도 이 Apache Ftp 서버를 이용해서 구현한 사례가 있습니다.  FTP client프로그램으로 붙어서 직접 HDFS로 파일을 올리거나, 다른 프로그램에서  ftp프로토콜을 이용해 HDFS에 접근할 수 있는 것이죠.^[각주:1]

   흥미로운 점은, 이 FTP서버에서는 스프링 방식의 설정을 지원한다는 것입니다. 예를 들면,  데이터베이스로 사용자를 관리할때, 익숙한 bean태그를 이용해서 datasource의 선언을 할 수 있습니다.

 <db-user-manager encrypt-passwords = "clear">
       <data-source>
         <beans:bean class="org.apache.commons.dbcp.BasicDataSource">
                  <beans:property name="driverClassName" value="${jdbc.driverClassName}" />
                  <beans:property name="url" value="${jdbc.url}" />
                  <beans:property name="username" value="${jdbc.username}" />
                  <beans:property name="password" value="${jdbc.password}" />
                  <beans:property name="initialSize" value="${dbpool.initialSize}" />
              </beans:bean>
        </data-source>

.....

더욱 재미있게도, 배포된 소스 ^[각주:2]중 examples폴더를 보면, Spring DM을 이용해서 OSGI번들로 apache FTP서버를 활용하는 예제가 나옵니다. META-INF/spring/bundle-context.xml의 파일을 보면 아래와 같이 선언되어 있습니다.

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi"
    xmlns:ftp="http://mina.apache.org/ftpserver/spring/v1"
    xsi:schemaLocation="http://www.springframework.org/schema/beans  
       http://www.springframework.org/schema/beans/spring-beans.xsd                     
       http://www.springframework.org/schema/osgi 
       http://www.springframework.org/schema/osgi/spring-osgi.xsd
       http://mina.apache.org/ftpserver/spring/v1
       http://mina.apache.org/ftpserver/ftpserver-1.0.xsd ">
    <ftp:server id="server">
        <ftp:listeners>
            <ftp:nio-listener name="default" port="2222" />
        </ftp:listeners>
        <ftp:ftplets>
            <ftp:ftplet name="ftplet1">
                <ref bean="ftplet" />
            </ftp:ftplet>
        </ftp:ftplets>
        <ftp:file-user-manager
            url="org/apache/ftpserver/example/osgiservice/users.properties" />
    </ftp:server>
    <osgi:service interface="org.apache.ftpserver.FtpServer"   ref="server">
    </osgi:service>
    <osgi:reference id="ftplet" interface="org.apache.ftpserver.ftplet.Ftplet" />     <bean class="org.apache.ftpserver.example.osgiservice.impl.FtpServerLifecycle"
       init-method="init" destroy-method="destroy"    >
       <property name="server" ref="server" />
    </bean>

</beans>

   FTP 서버 역할을 하면서 확장된 기능이 필요하고, 모듈을 재배포하는 도중에도 멈추지 않아야하는 서비스를 만들어야 할 때가 생긴다면,  Apache Ftp Server + Spring DM의 조합을 사용해서 편하게 구현을 할 수 있을 것으로 보입니다.

2009.04.30  수정이력 :
 해당 프로젝트 사이트에 대해서 잘 못 전달될 수 있는 내용이 글에 포함되어서, 해당 부분은 삭제했습니다. 해당 사이트의 극히 일부 개발자의 단순한 언급, 그것도 농담일 수도 있는 내용이 다수의 반응처럼 오해될 수 있는 부분이 있었고, 공식 발표 내용에는 포함되지 않은 내용도 있어서 본의아니게 발표자나 관련 사업자분들께 누를 끼쳐드린 것 같습니다. 비록 익명으로 된 해당사례가 올라와 있지만, 제가 보다 신중을 기하지 못하여 마음을 상하신 분들이 있다면  사과드립니다. 그리고 글 후반후에 제가 다른 발표에서 받은 질문과 일반적인 내용에 대해서 덧붙여서 언급한 내용이 있는데, 해당 사이트 사례와 전혀 관계가 없지만, 글을 빨리 읽으시는 분들께는 연결해서 생각할 수 있는 오해의 여지가 있을 것 같아서 그 부분도 삭제했습니다.  이 포스트에 포함된 내용으로 사실과 다르게 사례가 전달된다면 전적으로 제 잘못입니다.
  이 포스트를 포함하여 글의 내용에 대한 문의와 정정요청은 benelog[at]gmail[dot]com으로 해주시면 업무시간 외의 시간에는 최대한 빨리 답변드리겠습니다.  

•  발표자료 : http://www.jco.or.kr/conference/data/10th/Tiger-3.zip
  

  물개선생님 김승권님이 2009년 JCO 컨퍼런스에서 발표하신, 국내 대형 보험사에 Spring batch 기반으로 배치프레임웍을 적용한 사례입니다. 해당 보험사는 처리 자료 건수가 1억건 단위에 운영인력 50명, 800여건 작업을 돌리는 큰 규모의 배치 시스템을 가지고 있다고 합니다. 

   그 프로젝트에서는 개발자들이 더 쉽게 프레임웍을 적용하기 위해서 Job의 유형별로 설정을 간편하게 만들 수 있는 FactoryBean을 제공했다고 합니다.   그렇게 Job유형별로 설정이 정리되니, Spring의 설정파일을 읽어서 배치Job에 대한 정리된 정보와 통계까지 볼 수 있는 관리화면도 제공할 수 있게되는, 처음에는 생각하지 않았던 장점도 생겼다고 하네요. 저도 프로젝트에서는 같은 유형의 Job의 설정에는 중복코드가 없게 하기 위해서 유형에 따른 FactoryBean을 만들고 bean 설정에서 parent 속성을 이용했었는데, 그런 시도는 스프링배치를 실무에 적용할 때 프로젝트의 특수성을 반영하면서도 간편한 코드를 만들기 위한 필수적인 절차라고 생각되었었습니다.

  그리고, 중간의 Wrapping 계층을 두어서 최종 개발자들의 요구사항을 반영할 수 있는 확장점을 만들고, Spring batch의 API변화에 대처할 수 있도록 했다고 합니다. 재미있게도, 이 구조가 ItemProcessor 등 Spring batch 2.0구조와 상당히 비슷해서 프로젝트 내부의 정보가 스프링 쪽에 세어나간  것이 아닌가 하는 농담도 나왔었다고 합니다. ^[각주:1]

http://static.springsource.org/spring-batch/migration/2.0-highlights.html

http://forum.ksug.org/viewtopic.php?f=6&amp;t=468

Spring Batch 1.0에서 2.0으로 진화하기- 1. ItemReader/ItemWriter(1)

Spring Batch 1.0에서 2.0으로 진화하기- 1. ItemReader/ItemWriter(2)

Spring Batch 1.0에서 2.0으로 진화하기- 3. JobExecutionLisneter &amp; 4. ItemProcessor

Spring Batch 1.0에서 2.0으로 진화하기- 5. Configuration

'>

  그 외에도 기술 지원을 위한 프레임웍 운영팀의 역할이 커졌던 점과 프레임웍 적응을 위한 학습기간이 필요했던 점,  개발계보다 훨씬 많은 건 수의 데이터가  Skip이 일어날 수 있는 운영계의 데이터 특성이 개발계에서 모두 반영되지 못해서 나중에 대처를 했었던 사례 등을 들을 수 있었습니다.

- 정상혁  (http://benelog.egloos.com)

  스프링배치를 처음 접할 때는 만들어진 Job을 어떻게 빌드하고, 실행시킬지가 감이 잘 잡히지 않을 수도 있습니다. Qurtz를 이용한 스케쥴링을 하고 Web Application Server안에서 실행시킨다면 다른 Web application과 같이 배포시킬 수도 있을 것입니다. 그래도  스프링배치 연재(10) JobLauncher와 Job, Step에 서 소개한 것처럼 CommandLineJobRunner 를 사용하여 직접 console에서 실행시키는 것이 가장 기본적인 실행법이라고 생각됩니다. 그리고 스케쥴링도 하루에 4~5번 정도 실행되는 정도의 작업이라면, 초기 클래스 로딩시간에 대한 큰 부담이 없으므로 Cron을 배치잡을 실행하는 스크립트를 호출하는 것이  더 간편하기도 합니다. 이처럼 command line에서 바로 배치잡을 실행시킬 때, Job이 참조하는 jar파일들을 같이 묶고, 실행할 때 그 jar들을 classpath에 지정하는 스크립트를 만드는 과정을 정리해 봅니다.

   먼저 배치Job을 실행시킬 수 있는 스크립트를 만들어 봅니다. -classpath 지정을 특정 디렉토리 아래에 있는 *.jar파일을 다 포함시키도록 만드는 것이 편리합니다. Tomcat 같은 java application을 실행시키는 쉘스크립트를 보면, 이런 부분이 다 유사하게 들어가 있습니다.

   다음은 Windows 계열에서 실행시킬 수 있는 runJob.bat파일의 예제입니다. JAVA_HOME 환경변수에 실행하고자 하는 JAVA버전이 있는 디렉토리가 지정되어 있어야 합니다. 스크립트가 있는 곳 아래 /lib 폴더 아래에 job에서 참조하는 jar파일이 있는 것으로 설정했습니다.

@echo off
set JAVA_CMD=%JAVA_HOME%\bin\java
set MAIN_CLASS=org.springframework.batch.core.launch.support.CommandLineJobRunner
set CLASSPATH=.
FOR %%F IN (*.jar) DO call :addcp %%F

FOR %%F IN (lib\*.jar) DO call :addcp %%F
goto extlibe

:addcp
set CLASSPATH=%CLASSPATH%;%1
goto :eof

:extlibe

"%JAVA_CMD%" -Xmx512M -cp "%CLASSPATH%" %MAIN_CLASS% %*

  이 파일을 이용해서 특정 Job을 실행시키는 스크립트를 따로 만들 수 있습니다.

cd /D D:\workspace\imaso-batch\deploy
runJob.bat applicationContext.xml teamDbToXmlJob %*

   CommandLineJobRunner의 형식과 마찬가지로 runJob.bat [설정파일명] [Job의 bean id] [파라미터1] [파라미터2]... 의 형식입니다. 설정파일에는 해당하는 Job에 대한 설정과 공통적인 JobLauncher, Database에 대한 설정 등 Job에서 필요한 모든 설정이 다 포함되어야 합니다. 공통적인 부분과 특정 Job에만 필요한 것을 잘 분리해서 include 등을 이용해서 applicationContext 파일을 구성하는 것이 여러 Job을 관리할 때 효율적인 것입니다.

  다음은 리룩스나 유닉스에서 실행되는 runJob.sh 쉘스크립트의 예제입니다. run.bat와 마찬가지로 실행위치/lib에 참조하는 라이브러리의 jar파일이 했지만, imaso-batch.jar라는 파일하나는 실행위치 디렉토리에 있는 것을 따로 지정하도록 했습니다.

#!/bin/sh
BASEDIR=`dirname $0`
cd $BASEDIR

CLASSPATH=$BASEDIR
CLASSPATH=$CLASSPATH:$BASEDIR/imaso-batch.jar

for f in `find $BASEDIR/lib -type f -name "*.jar"`
do
   CLASSPATH=$CLASSPATH:$f
done

JAVA_BIN=$JAVA_HOME/bin/java
OPT="-cp $CLASSPATH -Xmx512M"

echo $JAVA_BIN
$JAVA_BIN $OPT org.springframework.batch.core.launch.support.CommandLineJobRunner

  runJob.sh를 이용해서 특정 Job을 실행시키는 스크립트를 다음과 같이 만듭니다.

#!/bin/sh
BASEDIR=`dirname $0`
cd $BASEDIR
sh runJob.sh applicationContext.xml teamDbToXmlJob "${1+$@}"

  이제 이런 스크립트와 jar파일들을 같이 배포할 수 있도록 Maven에 설정을 추가합니다.

  pom.xml에 배포시 필요한 jar파일들을 같이 복사할 수 있도록 <build/>절 밑에 다음과 같이 maven-dependency-plugin의 설정을 추가합니다. 예제에서는 ${basedir}/deploy/lib 폴더로 복사되게 했습니다.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-dependency-plugin</artifactId>
  <version>2.0</version>
  <executions>
    <execution>
      <id>copy-dependencies</id>
      <phase>package</phase>
      <goals>
        <goal>copy-dependencies</goal>
      </goals>
      <configuration>
        <outputDirectory>${basedir}/deploy/lib</outputDirectory>
        <overWriteReleases>false</overWriteReleases>
        <overWriteSnapshots>false</overWriteSnapshots>
        <overWriteIfNewer>true</overWriteIfNewer>
      </configuration>
    </execution>
 </executions>

</plugin>

   그리고 Job의 구성을 위해 작성한 xml파일과 class파일들을 jar로 묶을 수 있도록 jar plugin을 설정합니다. ${basedir}/deploy로 복사하도록 했습니다.

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-jar-plugin</artifactId>
   <configuration>
     <outputDirectory>${basedir}/deploy</outputDirectory>
    </configuration>
</plugin>

   마지막으로 처음에 작성한 스크립트 파일들이 ${basedir}/deploy로 복사되도록 resources-plugin 설정도 추가했습니다. 원래 Maven Super POM에서 스크립트들의 디렉토리가 src/main/scripts로 지정이 되어 있는데, 어떤 플러그인에서 기본적으로 참조되는 지는 파악이 잘 안 됩니다. (아시는 분은 알려주셨으면 합니다.)

<plugin>
   <artifactId>maven-resources-plugin</artifactId>
   <version>2.3</version>
   <executions>
     <execution>
       <id>copy-resources</id>
       <phase>package</phase>
        <goals>
        <goal>copy-resources</goal>
        </goals>
        <configuration>
        <outputDirectory>${basedir}/deploy/</outputDirectory>
        <resources>
        <resource>
        <directory>src/main/scripts</directory>
       </resource>
       </resources>             
       </configuration>           
       </execution>
     </executions>
</plugin>

  이렇게 설정한 후 mvn package를 실행하면 ${basedir}/deploy 아래에 스크립트, 참조라이브러리, 직접 작성한 application의 jar파일들이 같이 생성됩니다. 이 디렉토리를 개발팀에서 쓰고 있는 배포방식을 이용해서 서버로 복사하게 합니다. Hudson에서 제공하는 FTP업로드 기능 등도 이럴 때 활용할 수 있겠습니다.

  배포된 서버에서 스케쥴링을 하고 싶다면 runJob.bat, runJob.sh나 이럴 이용한 스크립트를 crontab에 설정하면 됩니다. 실행되는 OS user나 JAVA_HOME 등의 환경변수값이 잘 넘어가는지 유의해야 합니다. 

  pom.xml파일이나 runJob.sh, runJob.sh의 스크립트는 imaso-batch.zip에 포함되어 있습니다.

- 정상혁, http://benelog.egloos.com

정상혁

이미 35개 이상의 Accenture 고객사에 Spring batch가 적용되고 있다

스프링배치 연재(1) 배치처리의 특징

스프링배치 연재(2) 대용량 처리 배치 프로그램을 만들 때 유의할 점

스프링배치 연재(3) 스프링배치 프로젝트와 주요 기능들

스프링배치 연재(4) 스프링배치의 구조와 구성요소들

스프링배치 연재(5) ItemReader와 ItemWriter

스프링배치 연재(6) 플랫파일 읽기와 쓰기

스프링배치 연재(7) XML파일 읽기와 쓰기

스프링배치 연재(8) JDBC를 이용한 Cursor 기반의 DB 조회

스프링배치 연재(9) JobRepository

스프링배치 연재(10) JobLauncher와 Job, Step

스프링배치 연재(11) 재시작과 재시도

스프링배치 연재(12) 이벤트 처리, 유효성 검사, 변환, 기존 클래스 활용

스프링배치 연재(13) 스프링배치의 형제들

스프링배치 연재(14) 드라이빙 쿼리와 iBatis의 활용

스프링배치 연재(15) 하이버네이트 활용과 여러파일 읽기

스프링배치 연재(16) DB to XML 파일 만들기 예제

배치 어플리케이션 실행 스크립트와 빌드

박찬욱님

엘레강스한 배치 추상화 프레임웍 - 스프링 배치

[Beta 1.0]Spring Batch 프레임웍 레퍼런스 한글 편역 버전.

[Beta 2.0] Spring Batch 프레임웍 레퍼런스 한글 편역 버전.

[Beta 3.0] Spring Batch 프레임웍 레퍼런스 한글 편역 버전.

제 1부. 스프링 배치 기본 아키텍처와 잡(Job) 직접 실행해보기

제 2부. FlatFileItemReader와 그 친구들(파트1)

제 2부. FlatFileItemReader와 그 친구들(파트2) (소스 및 PPT)

제 3부. FlatFileItemWriter와 아이템 변환하기 (소스 및 PPT)

제 4부. StAX 기반 아이템 처리 (소스 및 PPT)

제 5부. 데이터베이스에 아이템 쓰고, 읽고~ (소스 및 PPT)

제 6부. 배치 반복 처리하기

Spring Batch 쓰임새 분석 - 단순한 배치 반복하기

Spring Batch 쓰임새 분석 - 자동적인 재시작

Batch Processing Strategies at Spring Batch 

스프링 배치's 액터(Actor)

Spring Batch 1.0에서 2.0으로 진화하기- 1. ItemReader/ItemWriter(1)

Spring Batch 1.0에서 2.0으로 진화하기- 1. ItemReader/ItemWriter(2)

Spring Batch 1.0에서 2.0으로 진화하기- 3. JobExecutionLisneter & 4. ItemProcessor

Spring Batch 1.0에서 2.0으로 진화하기- 5. Configuration

백기선님

The Domain Language of Batch - Spring Batch Chapter 2

ItemReader - Spring Batch Chapter 3

경구사님

Spring batch 개발환경 설정

김승권님

차세대배치시스템구축성공전략

 - [Spring batch]차세대 배치시스템 구축 성공전략 - JCO컨퍼런스

박재성님

Spring Batch 시작하기

KSUG포럼

SpringBatch에 대한 경험담을 듣고 싶습니다.

Spring Batch ItemReader 구현체에 대한 궁금증 

DB에서 2개 테이블을 엮어서 XML파일로 쓰기 예제

  DB에서 부모-자식 간의 관계로 된 테이블을 읽어서 하나의 XML로 만드는 작업은 실무에서 흔하게 만날 수 있는 배치처리 사례이다. 다음의 예제에서는 팀 테이블(team)과 선수(player)테이블에 DB에 있다고 가정하고 이를 하나의 XML로 만드는 작업을 진행해보고자 한다. 팀 테이블과 선수테이블은 당연히 1대 다 관계로 이루어져 있다. 테이블을 생성하고 테스트로 몇 개의 데이터를 넣어주는 스크립트가 첨부파일(imaso-batch.zip)에 포함되어 있다. (src/main/resources/data 폴더)

  먼저 부모 테이블인 팀 테이블을 읽어오는 ItemReader를 작성해 보자. JdbcCursorItemReader클래스를 이용해서 쿼리와 그 결과를 Team의 도메인 오브젝트로 매핑할 수 있는 mapper를 지정한다. (리스트12)

<bean id="teamMasterReader" class="org.springframework.batch.item.database.JdbcCursorItemReader">
   <property name="dataSource" ref="dataSource" />
   <property name="mapper">
      <bean class="org.springframework.jdbc.core.BeanPropertyRowMapper" >
         <property name="mappedClass"  value="imaso.batch.domain.Team"/>
       </bean>
     </property>
     <property name="sql">
        <value> SELECT  team_id, team_name, symbol, rank FROM team</value>
     </property>
</bean>

리스트 12 : JDBC커서 방식으로 Team테이블 조회

  간단한 코딩을 위해서 mapper에 BeanPropertyRowMapper를 사용하고 mappedClass속성을 team테이블의 내용을 담는 도메인 오브젝트인 Team클래스로 지정했다. Team 클래스는 team 테이블의 컬럼명이 그 멤버변수로 선언되고 있고, getter,setter를 가진 단순한 클래스이다. Java의 일반적인 명명규칙에 맞추어서 언더바(_)가 없이 camel casing으로 표기되어 있다. BeanPropertyRowMapper는 언더바와 camel casing간의 변환을 자동으로 해 주기 때문에 team_id의 컬럼도 setTeamId메소드를 통해서 값이 채워지게 된다. 만약 성능을 조금이라도 향상시키고 싶다면 다소의 추가 코딩을 하더라도 별도의 RowMapper를 구현해서 사용하기 바란다.

  이제 team의 자식 테이블인 player를 읽을 차례다. 여러가지 방법이 있겠지만, DrvingQuery방식과 비슷하게 team 1건마다 그 팀에 소속하는 선수를 조회하는 쿼리를 던지는 방식을 사용해 보았다. 이를 위해 상위테이블만 읽어온 item object에서 그 자식 테이블을 읽어서 채워줄 수 있는 경우를 추상화하여 ItemWithChildrenReader라는 클래스를 작성해 보았다.

public abstract class ItemWithChildrenReader extends DelegatingItemReader{

  public Object read() throws Exception {
  Object item = super.read();
    if(item==null) return null;
      setChildren(item);
      return item;
   }
    protected abstract void setChildren(Object item);
   public ItemWithChildrenReader() {}

}

리스트 13: 부모-자식 테이블 조회기능을 추상화한 클래스

  이를 상속한 클래스에서 setChildren메소드를 구현하여 자식 테이블을 읽어서 넣도록 설계된 것이다.
  Team테이블에서 읽어온 값에서 Player테이블을 채워줄 수 있는 ItemReader는 리스트 14와 같이 구현하였다.

public class TeamReader extends ItemWithChildrenReader {
private RowMapper mapper;
private JdbcTemplate jdbcTemplate;
private String sql;
protected void setChildren(Object item) {
    Team team = (Team)item;
    Object[] params = new Object[]{team.getTeamId()};
    @SuppressWarnings("unchecked")
    List<Player> playerList = jdbcTemplate.query(sql, params, mapper);
    team.setPlayerList(playerList);
}
 // private 멤버 객체에 대한 setter 생략
}

리스트 14ㅣ Player를 읽어서 Team에 넣어주는 클래스

  setChild메소드 안에서 JdbcTemplate, RowMapper를 이용하여 player테이블의 건들을 읽어와서 team객체에 넣어준다. 만약 두 테이블을 연결시키는 키 속성명, 결과가 들어갈 속성명까지도 설정파일로 빼고 BeanUtils클래스의 setProperty, getProperty들을 활용한다면 보다 일반화시킨 클래스를 만들 수도 있다.
TeamReader의 설정에는 앞에서 나온 Team테이블을 읽어오는 TeamMasterRead를 itemReader속성으로 지정해 준다.

<bean id="teamReader"  class="imaso.batch.item.TeamReader">
   <property name="itemReader" ref="teamMasterReader" />
    <property name="sql">
       <value>
        SELECT team_id, player_id ,player_name, main_position
        FROM player  WHERE team_id = ?
  </value>
 </property>
<!-- mapper, jdbctemplate에 대한 설정은 생략 -->
</bean>

리스트 15 : TEAM과 PLAYER를 같이 읽어오는 클래스의 설정

  만약 위의 구현처럼 쿼리를 건마다 하나씩 던지고 싶지 않다면, 다소 구현이 복잡해 지더라도 team과 player 테이블 모두 team_id를 기준으로 정렬해서 조회한 후에 sorted merge 방식과 유사하게 양쪽 item들의 team_id값을 비교해 가면서 team에다 player를 붙여주는 구현도 가능하다.

  그 다음은 읽어온 내용을 XML파일로 쓰는 기능은 StaxEventItemWriter와 XStream 라이브러리를 같이 사용해서 구성했다. XStream 라이브러리를 보다 잘 활용하기 위해서 반드시 프로젝트가 의존하고 있는spring-oxm을 최신버전인 1.5.4로 참조해서 쓰기 바란다. 스프링배치의  샘플 프로젝트에서는 1.0.0버전을 참조하고 있는데, 당연히 최신버전에 비해 기능이 많이 빠져있다. 그리고 앞으로 설명한 아노테이션을 이용한 태그명 설정을 사용하기 위해서는 spring-oxm-tiger 라이브러리도 포함시켜야 한다. 예제에서 사용한 Maven2의 pom.xml파일은 첨부파일 내에 포함되어 있다.
 생성시킬 XML파일의 형태는 team태그 밑에 team 컬럼의 속성들이 들어가고 player테이블의 내용은 team 태그 밑에서 player태그로 여러 번 반복된다. (리스트 16)

<content>
<team> <team_id>1</team_id> <team_name>Lotte</team_name> 
    <symbol>Giants</symbol><rank>1</rank>
    <player>
      <playerId>0</playerId> <player_name>이대호</player_name>
      <main_position>3루수</main_position>
    </player>
    <player>....</player> <player>....</player>
   <team>...</team>   
   <team>...</team>
</content>

리스트 16 : 생성할 XML파일

앞의 teamReader에서 읽어온 내용을 쓰기 위한 StaxEventItemWriter을 리스트17과 같이 설정한다.

<bean id="teamXmlWriter"   class="org.springframework.batch.item.xml.StaxEventItemWriter">
    <property name="resource"  value="file:target/team.xml" />
    <property name="serializer" ref="teamSerializer" />
    <property name="rootTagName" value="content" />
    <property name="overwriteOutput" value="true" />
</bean>
<bean id="teamSerializer"  class="org.springframework.batch.item.xml.oxm.MarshallingEventWriterSerializer">
    <constructor-arg ref="teamMarshaller"/>
</bean>

리스트 17 : StaxEventItemWriter의 설정

 루트태그명을 rootTagName에서 content로 지정하고 xml을 생성하는데 필요한 요소들을 serializer속성-> MarshallingEventWriterSerializer 클래스-> teamMarshaller 빈으로 연결시켜 주는 것까지는 기본적인 사용법과 별차이가 없다.
여기서 도메인 오브젝트인 Team과 Player클래스에서 태그를 연결하기 위한 설정을 편하게 하기 위해서 아노테이션을 사용했다. AnnotationXStreamMarshaller를  사용하면 도메인 오브젝트 내에서 리스트18처럼 태그를 지정해 줄 수 있다.

public class Team {
@XStreamAlias("team_id") private int teamId;
@XStreamAlias("team_name") private String teamName;
private String symbol;
private int rank;
@XStreamImplicit private List<Player> playerList;

리스트 18 : 태그명을 어노테이션으로 지정

  @XStreamAlias 어노테이션을 이용해서 멤버변수의 이름과 태그명이 다른 경우에는 태그명을 명시해 준다. playerList필드처럼 Collection이면서, 그 필드의 이름 자체는 태그로 옮기어 지지 않을 경우에는 @XStreamImplicit 어노테이션을 이용한다. 즉, 우리가 만들고자 하는 샘픔에서 playerList속성과 대응되는 부분이 <playerList><player/><player/></playerList> 의 형식처럼 player태그를 playList태그가 한번 감싸고 있는 것이 아니고 바로 <player/>가 반복되는 형태이기 때문에 @XStreamImplicit가 붙어야 하는 것이다. Player클래스에서는 team_id 멤버 변수는 아예 태그로 옮기어 지지 않으므로 @XStreamOmitField 어노테이션을 붙여서 이를 명시했다. XStream의 annotation에 대한 자세한 설명은 http://xstream.codehaus.org/annotations-tutorial.html페이지를 참고하기 바란다.
  어노테이션을 사용하지 않는다면 AnnotationXStreamMarshaller의 상위클래스인  XStreamMarshaller 를 사용하고,  implicitCollection, omittedFields의 속성에 Map의 형태로 생략할 필드들을 지정할 수 있다.
  또 하나 주의할 점은 태그명에 언더바(_)가 들어가면 XStream에서는 디폴트로 그것을 언더바2개(__)로 바꾸어 준다는 점이다. 이 것은 XStream의 XmlFriendlyReplacer라는 클래스에서 하는 작업인데, 불행히도 현재의 AnnotationXStreamMarshaller클래스에서는 이 클래스를 바꿔치기 할 수 있는 기능이 없다. 그래서 AnnotationXStreamMarshaller를 상속하는 별도의 클래스를 만들고 XmlFriendlyReplacer를 끼워넣을 수 있도록 구현을 했다. 

public class ExtendedXStreamMarshaller extends AnnotationXStreamMarshaller{
private XmlFriendlyReplacer replacer;
protected void marshalSaxHandlers(Object graph,
ContentHandler contentHandler, LexicalHandler lexicalHandler)
      throws XmlMappingException {
SaxWriter saxWriter = new SaxWriter(replacer);
saxWriter.setContentHandler(contentHandler);
getXStream().marshal(graph, saxWriter);
}
//replacer에 대한 setter 생략
}

리스트 19 : XmlFriendlyReplacer 를 지정할 수 있는 확장 클래스

 XmlFriendlyReplacer상속한 DummyReplacer를 만들고 여기서는 언더바를 더블언더바로 바꾸는 동작을 수행하지 않도록 만든 후 이를 setter로 설정했다.

<bean id="teamMarshaller" class="imaso.batch.item.support.ExtendedXStreamMarshaller">
   <property name="annotatedClasses">
     <list><value>imaso.batch.domain.Team</value>
         <value>imaso.batch.domain.Player</value>
     </list>
   </property>
   <property name="replacer">
      <bean class="imaso.batch.item.support.DummyReplacer"/>
    </property>
</bean>

리스트 20 : Marshaller설정

  annotatedClasses속성으로 Team과 Player클래스를 지정해서 어노테이션을 XStream에서 인식할 수 있도록 해준다.
  StaxEventItemReader에는 이 밖에도 다양한 형태의 Xml 생성을 돕는 속성들이 있다. Root태그 밑에 여러 속성들이 있다면 rootElementAttributes 속성에 Map형식으로 이를 지정할 수 있다. 예들 들어 “<content id=”baseball”>”으로 XMl이 시작한다면 id가 key이고 baseball이 value인 Map을 지정해 주면 된다. 그리고 headerItems속성으로는 루트 태그 아래에 추가로 들어갈 다른 태그들을 넣을 수 있다. 이와 함께 XStream에서 제공하는 Converter인터페이스를 구현하고 XStreamMarshaller 의 converters 속성으로 그것을 등록해 주면, 객체가 태그로 바뀌는 형식을 보다 정교하게 구현할 수도 있다. 자세한 내용은 첨부파일에 있는 예제를 참고하기 바란다.

   ItemReader와 ItemWriter를 연결시키는 Step과 Job의 설정을 하면 모든 작업은 끝이 난다. 주의할 점은 SimpleStepFactoryBean에서는 ItemReader가 Writer가 바로 동시에 ItemStream이라면 자동으로 stream속성에 등록이 되는데, 다른 ItemStream객체가 있다면 따로 지정을 해 주어야 한다는 것이다. DelegatingItemReader안에 감싸져서 들어가는 itemReader와 같이, Step에 직접 등록되는 ItemReader가 아닌 경우도 여기에 해당한다. 리스트12와 15에서 보이듯이,  teamMasterReader도 teamReader에 감싸져 있는 클래스인데, itemStream인 JdbcCursorItemReader클래스이므로, Step설정에서 streams에 지정되어 있어야지 open,update,close와 같은 메소드들이 제대로 호출될 수 있다.

<bean id="teamDbToXmlStep" parent="simpleStep"> 
  <property name="itemReader" ref="teamReader"/>
  <property name="itemWriter" ref="teamXmlWriter"/>
  <property name="streams" ref="teamMasterReader"/>
</bean>

리스트21: Step의 설정

첨부파일

imaso-batch.zip

-정상혁,  http://benelog.egloos.com

하이버네이트의 활용

  HibernateCursorItemReader 를 사용하면 하이버네이트를 사용하면서도, 지난 연재에서 소개했던 JdbcCurItemReader와 유사한 커서방식의 조회가 가능하다. 설정의 예는 리스트 8에 나와있다.

<bean id="hibernateItemReader"   class="org.springframework.batch.item.database.HibernateCursorItemReader">
    <property name="useStatelessSession" value="true" />
    <property name="queryString" value="from player" />
    <property name="sessionFactory" ref="sessionFactory" />
</bean>

리스트 8 : 하이버네이트를 이용한 조회

  sessionFactory 속성은 스프링에서 기본적으로 제공하는 LocalSessionFactoryBean 를 이용해서 설정한다. useStatelessSession 속성에 따라서 상태를 가지거나 안 가지는 Session이 생성된다.  useStatelessSession과 queryString이 하이버네이트의 코드와 어떻게 연결되는지는 리스트9에 있는 Query를 생성하는 부분을 보면 알 수 있다. StatelessSession이라면 하이버네이트에서 제공하는  Cache 와 Dirty체크 기능을 쓰지 않게 된다.

private Query createQuery() {
  if (useStatelessSession) {
   statelessSession = sessionFactory.openStatelessSession();
   return statelessSession.createQuery(queryString);
  } else {
  statefulSession = sessionFactory.openSession();
  return statefulSession.createQuery(queryString);
  }
}

리스트 9 : 하이버테이트와 연결되는 부분

 하이버네이트를 이용해서 DB에 자료를 저장하고 싶을 때도 HibernateAwareItemWriter라는 클래스도 도움을 줄 수 있다. 리스트9에 나와있듯이, 이 클래스에도 마찬가지로 sessionFactory를 속성으로 지정하고, 다른 하이버네이트를 쓰는 ItemWriter를 delegate에 연결시킨다.

<bean id="hibernateItemWriter"
  class="org.springframework.batch.item.database.HibernateAwareItemWriter">
  <property name="sessionFactory" ref="sessionFactory" />
  <property name="delegate" ref="playerWriter" />
</bean>

리스트 10 : 하이버네이트를 인식하는 ItemWriter

  HibernateAwareItemWriter는 트랜잭션의 한 묶음이 한꺼번에 commit 되었을 때 실패가 일어난다면, 어떤 item이 실패인지 알아보기 위해 실패한 묶음을 다시 한건 한건 쓰기 시도를 해준다. Jdbc의 batchUpdate를 이용하는 ItemWriter인 BatchSqlUpdateItemWriter의 경우에도 마찬가지의 흐름을 가진다.

여러 파일 읽기

  앞 선 연재에서 소개한 FlatFileItemReader 같은 파일읽기 클래스들은 읽을 파일을 resource속성을 통해서 지정한다.  실무에서는 읽어서 처리할 파일이 하나가 아니고 특정 디렉토리에 있는 파일 전체나 아니면 특정 확장자, 이름패턴을 가지고 있는 경우가 대부분일 것이다. MultiResourceItemReader클래스는 와일드 카드등을 이용해서 여러 파일들을 한꺼번에 지정할 수 있다. 리스트 11과 같이 resources 속성으로 파일들을 읽을 패턴을 지정하고, delegate속성에 그 resource를 읽을 itemReader를 연결시켜 준다.
<bean id="multiResourceReader" class="org.springframework.batch.item.file.MultiResourceItemReader">
  <property name="resources" value="classpath:data/multiResourceJob/input/file-*.txt" />

  <property name="delegate" ref="flatFileItemReader" />
</bean>

리스트 11 : 여러파일 읽기

정상혁, http://benelog.egloos.com

2008 올해의 스프링기술 Top 5

 권한,인증,보안 등의  모듈의 설계는 어느 시스템이나 필수적이고, 많은 고려 사항이 들어가야 하는 부분입니다.  그래서, 경험이 있는 개발자라면 이 것이 원래 복잡한 영역이라는 것에  동의할 것입니다.  이 권한 등의 관련 모듈은 유연하면서 충분한 기능을 담도록 만들기가 쉽지 않고, 매번 새로운 시스템마다 반복적으로 설계, 개발되는 경우도 많습니다. 그렇기에 이 영역에서 Spring Security의 존재가 가치있게 느껴집니다. Spring이 간단한 개발을 괜히 복잡하게 만드는 것이 아니고, 필수적으로 복잡한 요구사항이 충족되어야 하는 영역을 이미 만들어진 모듈을 쓰면서도 더 유연한 구조를 제공을 한다는 것을 Spring Security를 통해서 보여주고, 공감을 이끌어낼 수 있다고 생각합니다. 그런 의미와 2008년 들어 더욱 빨라지고 있는 것으로 보이는 발전속도, 적용 사례의 증가가 돋보이기에 2008년의 Spring 기술중 하나로 선정했습니다.

4. SpringSourceTool Suite

  SpringSourceTool Suite는 스프링이 이제 개발자의 더 가까운 곳에서 더 자세히 개발을 도와주는 역할을 주겠다는 의미로 다가옵니다. 그리고 스프링의 상용제품 출시를 본격적으로 알리는 신호탄으로, 앞으로의 스프링소스의 사업모델의 측면에서 보아도 이 제품이 중요한 분기점의 의미가 되지 않나하는 생각이 듭니다.

3. Spring batch

  KSUG 블로그에 오시는 분들은 잘 아시다시피, 제가 올해 가장 큰 관심을 가졌던 배치 프레임웍입니다. Accenture의 현장경험이 잘 녹아들어가고 Spring기반의 기술이 이를 뒷받침해서 본격적으로 Java 배치프레임웍의 논의를 불러일으킨 기술이라고 생각합니다. 배치처리에 어떤 기능들이 필요할 지를 보다 고민하는 계기가 되고, 경험있는 개발자의 처리 방식을 참고하고 그대로 사용할 수도 있다는 것에서 스프링배치는 큰 의미가 있습니다. 아직 젊은 프로젝트라서 1.X의 버전에서는 분산처리 같은, 성숙한 유사 모듈에 있는 기능들이 빠진 것들도 보이지만, 내년 2.0 발표 등으로 보다 강력한 프레임웍으로 발전해 나갈 것으로 예상됩니다.

2. Spring 2.5

 Spring 2.5가 발표된 것은 작년이였지만, 본격적으로 주변에서 적용되는 것을 본 것은 올해라고 느껴집니다. 개발자들이 하위 호환성에 대한 걱정을 크게 하지 않으면서 기존 모듈의 의존성을 Spring 2.0에서 2.5로 업그레이드하는 사례를 여러번 봤는데, 이런 현상은 Spring에 대한 신뢰성이 깊어졌으면서도 그 발전 속도에 개발자들이 적응을 하게 된 것 같다는 의미부여를 하고 싶습니다. 

  이 기술의 발표 소식을 듣는 순간 과연 스프링의 영역이 어디까지 뻗어나갈까 하는 감탄이 들었습니다. 그리고 앞으로 퍼져나갈 OSGi 세상에서도 Spring이 단순 프레임웍 이상의 큰 역할을 할 것이라는 확신을 심어준 사건이였죠.

2009 유망 스프링 기술 Top

5. Spring Web Flow

javascript, JSF 지원기능 등 더욱 확장된 영역으로, 이제는 앞으로는 기본 웹개발은 SpringMVC, 보다 많은 기능이 필요한 웹개발은 Spring Web Flow이 맡게 되지 않을까하는 예감이 듭니다.

4. Spring Integration

  현재 1.0 마일스톤 버전이 발표되어 있습니다. 1.0 최종버전이 나오면 본격적으로 Spring Integration을 적용해보고 싶어하는 개발자가 많을 것 같습니다. 데이터 연계(Integration) 모듈도 어느 시스템에나 있는 것이고, Spring Integration은 다양한 종류의 자원들을 동일한 방식으로 연결시켜주는 기능을 제공하므로, 많은 기대를 가지게 합니다.

3. Spring DM

 아마도 내년이 Spring DM의 본격적인 대중화 시기가 되었으면 합니다. 대부분의 개발자들에게 낯선 OSGi 세계에서도 스프링이 든든한 길잡이가 되어줄 것으로 믿습니다.

2. Grails

  이미 JVM위에서 돌고 있는 스크립트 언어가 200여가지라고 하죠. (http://www.is-research.de/info/vmlanguages/ ) 필요한 영역에 따라 JVM위에서 돌아가는 Script언어를 사용하게 될 것이라는 예상은 몇년전부터 있어왔는데, 아직까지 그 기대에 비하면 적용된 곳이 많지 않아 보입니다. 그래도 JVM 위의 Script언어 중 가장 많이 알려진 Groovy 바탕 위에서 Ruby on Rails의 뜨거운 열풍을 탄 Grails를 SpringSource까지 밀어준다는 소식은 Java web개발의 대전환기가 멀지 않았다는 느낌을 들게 합니다.

1 .Spring 3.0