1. 설치하기

http://www.jfrog.org/sites/artifactory/latest에서 최신 버전을 다운로드하고 적절한 디렉토리에서 압축을 푼다.

2. 설정하기
$ARTIFACTORY_HOME/etc에 있는 artifactory.config.xml 파일을 아래과 같이 수정한다.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://artifactory.jfrog.org/xsd/1.1.0"
xsi:schemaLocation="http://artifactory.jfrog.org/xsd/1.1.0
http://www.jfrog.org/xsd/artifactory-v1_1_0.xsd">
<localRepositories>
<localRepository>
<key>daum-internal-repository</key>
<description>daum internal repository</description>
<handleReleases>true</handleReleases>
<handleSnapshots>true</handleSnapshots>
</localRepository>
<localRepository>
<key>third-party-repository</key>
<description>third party repository</description>
<handleReleases>true</handleReleases>
<handleSnapshots>true</handleSnapshots>
</localRepository>
</localRepositories>
<remoteRepositories>
<remoteRepository>
<key>ibiblio</key>
<handleReleases>true</handleReleases>
<handleSnapshots>false</handleSnapshots>
<excludesPattern>org/artifactory/**,org/jfrog/**</excludesPattern>
<url>http://repo1.maven.org/maven2</url>
</remoteRepository>
<remoteRepository>
<key>codehaus-snapshots</key>
<blackedOut>true</blackedOut>
<handleReleases>false</handleReleases>
<handleSnapshots>true</handleSnapshots>
<excludesPattern>org/artifactory/**,org/jfrog/**</excludesPattern>
<url>http://snapshots.repository.codehaus.org</url>
</remoteRepository>
<remoteRepository>
<key>apache-m2-snapshots</key>
<handleReleases>false</handleReleases>
<handleSnapshots>true</handleSnapshots>
<url>http://people.apache.org/repo/m2-snapshot-repository</url>
</remoteRepository>
<remoteRepository>
<key>apache-snapshots</key>
<handleReleases>false</handleReleases>
<handleSnapshots>true</handleSnapshots>
<url>http://people.apache.org/maven-snapshot-repository</url>
</remoteRepository>
</remoteRepositories>
</config>

3. 실행하기
$ARTIFACTORY_HOME/bin에서 artifactory.sh를 수행한다. 이 스크립트는 jetty를 이용해서 $JAVA_HOME 환경 변수 설정이 필요하다.
8081 포트로 artifactory가 실행된다.

4. settings.xml
~/.m2/settins.xml 파일을 아래와 같이 설정한다.
<settings xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<profiles>
<profile>
<id>gaia</id>
<repositories>
<repository>
<id>central</id>
<url>
http://media-install:8081/artifactory/repo
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>snapshots</id>
<url>
http://media-install:8081/artifactory/repo
</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>
http://media-install:8081/artifactory/repo
</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>snapshots</id>
<url>
http://media-install:8081/artifactory/repo
</url>
<releases>
<enabled>false</enabled>
</releases>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
</settings>

5. maven에서 artifactory 연결하기
mvn 실행시 settings.xml에서 정의한 프로파일을 정의하기 위해 '-Pgaia'를 지정하면 된다.

6. 정상적으로 동작하는지 확인하기
http://media-install:8081/artifactory로 접속 admin/password로 로긴한다. 왼쪽 메뉴에서 "Browsing/Repositories Tree"를 클릭해서 artifactory들이 보이면 정상 동작하는 것이다.

7. 3rd party artifact나 사내 artifact 등록하기
왼쪽 메뉴에서 "Deploy an Artifacts" 클릭. "찾아보기" 버튼으로 deploy할 artifact 선택하고, "Upload!" 버튼 클릭. 다음에 나오는 화면에서 groupId, artifactId 확인하고 적절하게 설정하고 deploy한다.

아래와 같은 코드를 예로 들어보자.

public class Customer {

private Long accountId;

public Long getAccountId() {
return accountId; }
}

public void setAccountId(Long accountId) {
this.accountId = accountId;
}
...
}

public class CustomerServiceImpl {
public Double getNetWorth(Customer customer) {

Long accountId = customer.getAccountId();

Account account = accountRepository.getAccountById(accountId);

return account.getValue();
}

}

위의 예는 전형적인 Anemic Domain Model이다(행위는 서비스 레이어에만 있고, 도메인 객체는 단순히 데이터 컨테이너 역할만 한다).

이를 해결하고자 할 때 부딪히는 가장 큰 문제는 Cutomer객체가 어떻게 Account객체를 얻느냐는 것이다. 이 문제에 대한 해결책은 아래와 같은 3가지가 있을 수 있다.

1. CustomerServiceImpl이 Account를 얻어서 Customer객체에 전달한다. 이 경우 CustomerServiceImpl은 여전히 2개의 비즈니스 로직에 참여하게 되서 위 코드와 별반 다를바가 없게 된다.
2. Cutomer객체가 service locator를 통해 능동적으로(actively) AccountRepository를 얻는다. 이 방법은 Customer 객체가 ArticleRepository와 service locator에 종속성(dependency)을 갖게 해서 transparent한 해결책이라 할 수 없다.
3. DI를 통해 ArticleRepository를 Customer 객체에 주입한다.

위 방법 중에 3안이 가장 이상적인 방안으로 보인다.

3안은 아래와 같이 구현될 수 있다.

@Configurable("smartCustomer")
public class SmartCustomer extends Customer {
private AccountRepository accountRepository;

public AccountRepository getAccountRepository() {
return accountRepository;
}

public void setAccountRepository(AccountRepository accountRepository) {
this.accountRepository = accountRepository;
}

public Double getNetWorth() {
Account account = accountRepository.getAccountById(getAccountId());
return account.getValue();
}
}

@Configurable은 해당 클래스가 새로운 인스턴스가 생성될 때 Spring에 의해 DI되어야 한다는 표식이다. @Configurable이 붙은 클래스를 스프링에 등록해 주면 스프링은 그 객체가 생상될 때 그 객체가 필요로 하는 bean들을 주입해준다. 이를 위한 설정 파일은 아래와 같다.

<bean id="smartCustomer" abstract="true" class="org.springdallasug.aspectj.domain.SmartCustomer" scope="prototype" >
<property name="accountRepository" ref="accountRepository" />
</bean>

그리고 LTW로 DI가 발생하도록 하기 위해 JVM 실행 옵션에 아래 라인을 추가한다.

-javaagent:PATH_TO_JAR/aspectjweaver-1.5.0.jar

Pros and Cons
나도 같은 생각이지만 이 글의 필자도 도메인 객체에 DI를 적용하는 것이 맞는지 의문이라고 한다. 예제와 같은 스타일로 구현하게 되면 도메인 객체는 자신의 역할 수행(net worth 계산)을 위한 완벽한 로직을 갖게 되는 장점을 갖는다. 하지만 도메인 객체가 리파지토리를 사용함으로써 이상한 설계가 된다.
보다 풍부한(richer) 도메인 모델이 되지만 복잡해질 수도 있는 보다 많은 종속성이 도메인 모델에 생긴다.

구현 후기
- service 메소드가 인자로 Customer를 받으면 동작하지 않는다. SmartCustomer를 받아야만 제대로 동작한다.

참고자료

Domain 객체에 Repository를 inject해야 하나 ?

먼저 DAO와 Repository의 차이를 알아보자.

presentation <--> service <--> domain <--> data access

이런 관계에서 DAO는 data access layer에 속한다.
DAO는 CRUD 연산을 encapsulate하는데, ORM이 없는 상황에서는 RDB와 OO Technique 간의 impedence를 처리한다.

Eric Evans는 "객체는 더 이상 <자신의 의미나 상호작용에서의 역할 지원>과 관련된 코드가 없을 때 까지 정제되어야 한다"라고 한다.

@Configurable("organization")
class Organization {

// implementation needs to be injected
private EmployeeDAO employeeDao;

// ..
// ..
public List<Employee> getOutstationEmployees() {
List<Employee> emps = employeeDao.getEmployeesByAddress(corporateOffice);
List<Employee> allEmps = employeeDao.getAllEmployees();
return CollectionUtils.minus(allEmps, emps);
}
// ..
}

위의 코드에서 employeeDao를 통해 데이터를 준비하는 것은 Oraganization의 역할이 아니다. 이런 상세한 로직은 data access layer에 가까운 다른 추상화에 속해야 한다.

가장 이상적인 추상화 수준은 EmployeeRepository이다.

Repository의 역할은
- data accessors(Dao)와 상호작용을 추상화하는 분리된 레이어
- 도메인 모델에 "business interface"를 제공한다.

이런 경우 Employee aggregate(Employee 클래스는 Employee aggregate를 구성하는 Adress, Office 등과 같은 클래스와 연관을 갖을 수 있다)에 대해 하나의 Repository를 사용한다.

Aggregate의 리파지토리는 도메인 언어로 도메인 모델에게 data access 서비스를 제공하기 하기 위해 필요한 모든 Dao들과 상호작용하는 책임을 갖는다. 도메인 모델은 리파지토리 덕에 데이터 레이어로부터의 결과를 수집하는 것과 같은 상세 구현과 분리/유지될 수 있게된다.

public interface EmployeeRepository {
List<Employee> getOutstationEmployees(Address address);
// .. other business contracts
}

public class EmployeeRepositoryImpl implements EmployeeRepository {

private EmployeeDAO employeeDao;

public List<Employee> getOutstationEmployees(Address address) {
List<Employee> emps = employeeDao.getEmployeesByAddress(corporateOffice);
List<Employee> allEmps = employeeDao.getAllEmployees();
return CollectionUtils.minus(allEmps, emps);
}
}

리파지토리와 Dao의 주요 차이점은 아래와 같다.

• Dao는 리파지토리 하위의 추상화 단계로써 데이터베이스로부터의 데이터를 읽어오기 위한 배관 코드(plumbing code)를 가질 수 있다. 데이터베이스 테이블 마다 하나의 Dao를 사용하고, 하나의 도메인 타입이나 aggregate에 대해 하나의 리파지토리를 사용한다.
• 리파지토리가 제공하는 인터페이스/계약(contract)은 순수 "도메인 중심적"이고 같은 도메인 언어를 사용한다.

리파지토리는 도메인 구조물이다.

리파지토리는 도메인의 ubiquitous 언어를 사용한다. 그래서 리파지토리가 제공하는 인터페이스는 도메인 모델에 속한다. 하지만 리파지토리의 구현은 테이블 종속적인 메소드나 Dao를 사용하기 위한 배관코드를 갖는다. 그래서 순수 도메인 모델은 리파지토리 인터페이스에만 종속적이어야 한다. 마틴 파울러는 이를 위해 "Separated Interface" 패턴(http://www.martinfowler.com/eaaCatalog/separatedInterface.html - 리파지토리 인터페이스는 도메인 패키지 정의하고 구현은 다른 패키지. 클라이언트는 상세 구현을 완전히 몰라도 된다. Separated Interface는 Gateway를 위한 훌룡한 plug point가 된다.)을 추천했다.

도메인 모델에 리파지토리를 Inject하는 것은 아래와 같이 단순하다.

@Configurable("organization")
class Organization {
private String name;
private Address corporateOffice;
// .. other members

// implementation needs to be injected
private EmployeeRepository employeeRepo;

// ..
// ..

public List<Employee> getOutstationEmployees() {
return employeeRepo.getOutstationEmployees(corporateOffice);
}
// ..
}

하이버네이트 같은 ORM을 사용하게 되면 transparent persistence로 인해 Dao가 불필요해진다.

이러한 방식으로 구현된 어플리케이션을 수행하기 위해서는 아래와 같이 jvm에 옵션을 추가해야 한다.

-javaagent:/Users/msbaek/.m2/repository/org/springframework/spring-agent/2.5.2/spring-agent-2.5.2.jar

eclipse에서 아래 화면과 같이 설정하면 테스트 수행시마다 설정을 할 필요가 없어진다.

질의응답
Q1. 리파지토리 대신 Dao에서 Aggregate를 처리하면 되지않나 ?
A1. Dao는 높은 재사용성을 제공하는 fine grained 메소드를 제공. 리파지토리는 도메인 구조물로써 도메인 언어를 사용하고 Aggregation에 대한 coarse grained 메소드를 제공. Dao는 "outstation(출장소)"라는 도메인 언어의 해석을 포함면 안된다.

참고자료

• http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html

tomcat에 인스톨하기

mvn jetty:run-war: jetty로 웹 어플리케이션 실행

mvn cargo:start -Dcargo.wait=true: 톰캣에 어플리케이션을 디플로이한다. http://localhost:8081/applicationName-version

maven 2 tomcat plugin 설정(mvn tomcat:run, mvn tomcat:run-war)

<plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>tomcat-maven-plugin</artifactId>

<configuration>

<path>/</path>

</configuration>

</plugin>

이미 설치된 톰캣을 사용하고 할 경우 아래의 설정을

<container>

<containerId>${cargo.container}</containerId>

<!--home>${cargo.container.home}</home-->

<zipUrlInstaller>

<url>${cargo.container.url}</url>

<installDir>${installDir}</installDir>

</zipUrlInstaller>

</container>

다음과 같이 변경한다.

<container>

<containerId>${cargo.container}</containerId>

<home>${cargo.container.home}</home>

</container>

mvn test

-Dtest=ClassName(not fully-qualified)

-Dsurefire.useFile=false: test 오류를 파일이 아닌 콘솔에서 보고자 할 때

-Dmaven.surefire.debug: 5005번 포트로 디버그 포트를 열고 대기(suspend=y)할 때

dbunit을 이용해서 데이터베이스 export하기

mvn dbunit:export

target/dbunit/export.xml에 export됨. -Ddest 파라미터로 위치 변경 가능

repopulate database

mvn dbunit:operation

mvn hibernate3:hbm2ddl dbunit:operation

creates and populates your database