Whiteship's Note


AspectJ를 이용한 코드젠과 프레임워크 2

모하니?/Coding : 2009.06.10 19:57


이전 글 AspectJ를 이용한 코드젠과 프레임워크에 이어지는 글로 현재는 Service과 Controller까지도 적용을 마치고 실행 후 잘 돌아가는 모습을 살펴보습니다. 지금은 웹 쪽을 REST 스타일로 고칠겸, 새 프로젝트로 깔끔하게 정리하고, 새로 디자인한 것까지 모두 합치고 있습니다. (역시 적당한 단계별로 해야지 한꺼번에 하려니깐 정신없고 오래 걸리는 듯합니다.)

1. AJ 내에서 코드 젠을 이용하여 상속을 없앨 수 있다.

AJ 코드를 어떻게 작성하느냐에 따라 다르겠지만, ROO가 제공하는 AJ를 스타일대로 작성하면, 상속을 이용하지 않고도 추가 기능을 넣을 수 있다. 장담점이 있다고 생각된다. 상속을 없앤건 좋은 일이라고 생각된다. 프레임워크 코드가 아닌, 비즈니스 도메인에 의한 상속을 사용할 수 있을테니말이다. 하지만, 상속을 포기하고 일일히 다 주입하는 방법을 택하다보니, 비슷한 코드가 여러 AJ에 널려있게 된다. 이 때는 또 한 가지 변수 AJ 파일의 길이를 고려해야 할 것 같다. AJ가 일일히 작성하기에 너무 길다고 생각 된다면, AJ 상속 .. 보다는 AJ에도 Generic을 도입할 수 있다면 편할지 모르겠다. 또한 AJ 작성에 걸리는 시간을 감안할 때 AJ를 코드젠하는 기술은 거의 필수라고 생각된다. 하지만 AJ가 코드젠 없이도 만들만큼 분량이 적다면? 그렇다면 굳이 코드젠 없이 그냥 손수 AJ 파일을 만들어 쓰면 될 것 같다. 하지만 내가 오늘 작업해본 AJ 코드는 일일히 작성하기에는 너무 길었다. 코드젠이 필요하다고 느껴졌다. 

2. 테스트가 필요하다.

코드가 눈에 보이면 고치기도 간편하다. 그래서인지, 왠만큼 돌아갈 것으로 만단되는 코드는 테스트를 잘 하지 않는다. 복잡한 로직이나 확신이 없는 코드에 대한 테스트만 작성하는 편이다. 자신감이라기 보다는 게으름이 맞을 것이다. 아무튼.. 그런데 이 게으름을 부리지 못할 정도로 날 불안하게 만드는 것이 바로 AJ다. 내가 아직 AJ에 익숙하지 않아서 일지도 모른다. 그래서 인지 불안하다. 그래서 인지 테스트가 절실하다.


컨틀로러 코드는 비어있지만, 아래 보시다시피 엄청나게 많은 것들이 추가됐다. 잘 동작하는지 어떻게 확신할 수 있겠는가? 글쎄.. 확신하지 못하겠다. 오랜만에 컨트롤러 테스트를 해보게 생겼다.

가짜 데이터 -> 컨트롤러 메서드 -> 결과 확인

스타일로 해볼 생각이다. 예를 들어, 위에 보이는 것중에 delete(int)가 있다. 가짜 데이터는 int 타입 변수 하나가 될 것이고, 메서드에 넘겨주고, service.delete()가 호출되는지 확인할 것이다.

3. 자동완성과 코드 네비게이션에 대한 대안을 찾았다.

위에 보이는 Cross References 뷰를 이용하는 것이다. Ctrl + 스페이스와 Ctrl + 클릭에 비할바는 못 되지만, 어떤 것들이 주입되었는지 한눈에 볼 수 있고 클릭을 하면 바로 AJ 파일로 이동해 주기 때문에 어느 정도 B급 대안이 될 수 있지 않을까 생각된다.

4. 배포는 어떨까?

어제도 포스팅 했지만, 메이븐에서 AJ를 컴파일 하도록 설정해주기만 하면 배포에도 전혀 문제가 없다. AJ는 스프링 AOP와 달리 컴파일 시점 위빙을 사용할 수 있기 때문에 더 간편한 것 같다. 스프링 AOP처럼 agent 설정을 하지 않아도 되니 얼마나 좋은가. 심지어 메이븐 설정을 스프링 ROO예제에서 그대로 배낄 수도 있다.ㅋㅋ

5. 활용 방법이 여러 가지다.
 
잘 모르겠지만, 기존의 자바 프레임워크는 (이클립스 플러긴 같은 툴은 빼고) 아마도 Generic을 활용한 DAO, Service, Controller 추상 계층과, View 자동 생성 그리고 유틸 라이브러리를 제공해주는 것일 것이다. 여기에 AspectJ 활용을 극대화 하여 새로운 프레임워크를 만드는 방법이 몇 가지 있겠다.

a. 기존 프레임워크에 AJ 파일 소수(하나 내지 두개)를 추가하여 자동 (또는 수동으로) 생성되는 코드를 깔끔하게 만드는 방법이 있다.
b. 스프링 ROO처럼 기존에 Generic 클래스 상속으로 제공하던 기능들을 일일히 AJ로 주입해주는 것이다.
c. 위 두 가지 방법을 혼용하는 것이다.

이 셋의 차이점은 좀 더 코딩하면서 느껴봐야 확실해 지겠지만, 지금까지 느낀점을 간략하게 정리하자면 이렇다.

a: AJ 코드량과 생성된 코드량이 모두 적다. 생성된 코드가 POJO 처럼 보이지만 사실은 이전과 동일하다.(extends Generic머시기..) 코드젠이 필요없거나, 간단한 코드젠이 필요하다.

b: AJ 코드량이 엄청 많지만, 생성된 코드량은 적다. 생성된 코드는 POJO에 가깝다. 다소 복잡한 코드젠이 필요할 수 있다. AJ가 커서 여러 AJ로 나누는 것이 깔끔해 보일 수 있다.(스프링 ROO) 중요 로직이 눈에 확 띈다.

c: a방법을 사용하는 AJ와 b방법을 사용하는 AJ를 분리하는게 좋다. 결국엔 코드젠이 필요하다.

오늘의 결론

어떻게 하나 결국에 생성되는 코드는 (실제 그런지 어떤지를 떠나서) 깔끔해 보이기 때문에 핵심 로직은 눈에 확 들어 올 듯 하다. 하지만 그러기 위해서 드는 노고를 생각해보면... 이걸 내가 꼭... 해야되는건가.. 싶기도 하다. 특히 a 방법을 쓸꺼라면.. 그냥 겉치례에 불과하다고 느껴진다. 그럴바엔 그냥 기존 방식을 쓰는게 나아보인다. 많은 노고를 들여서 b 방법으로 개발해 낸다면.. 멋질 것이다. 스프링 ROO 처럼 말이다. 단, 스프링 ROO는 DDD 다른 또 다른 학습 부담이 있어서 망설여지지, 그렇지 않고 기존의 계층형 아키텍처 스타일로 b 형태의 프레임워크를 제공한다면, 어떨까?? OSAF-ROO가 되는건가..

top


AspectJ를 이용한 코드젠과 프레임워크

모하니?/Coding : 2009.06.08 20:54


오늘은 도메인과 DAO쪽에만 AOP를 적용하는 AspectJ 파일을 만들어보았습니다. ROO를 참고하면서 말이죠. ROO와 다른 점은 프레임워크 코드를 이용한다는 거죠. (ROO는 제품 코드에서 ROO 코드는 하나도 이용하지 않는 완전한 non-intrusive 내지 transparent 코드젠 기술을 제공합니다.) 이런 식으로 새로운 형태의 OSAF도 만들어 낼 수도 있겠습니다. 하지만.. 할지 말지는 고민을 해봐야겠네요.

그 고민에 대한 시작으로, 아직은 충분한 예제를 못 만들었지만, 일단 여기까지 AspectJ를 이용한 프레임워크를 만들면서 느낌점을 정리해봐야겠습니다.

1. 자동완성 기능 사용 못 합.

이전 글처럼, AspectJ로 (메서드를 추가하거나 클래스 또는 인터페이스 상속을 추가하여) 어떤 클래스에 추가적인 기능들을 줬지만, 막상 이클립스에서 해당 클래스를 써먹을 때 코드 자동 완성을 사용할 수 없다는 점입니다. 원래 해당 클래스가 가지고 있던 멤버는 당연히 자동 완성이 되지만, AspectJ로 주입한 기능들은 참조가 되지 않습니다. 이 점은 AJDT에서 개선해주면 가능할지 싶은데... STS 최신 버전에선 어떨지 모르겠네요. 아무튼.. 이게 안 된다면.. 아.. 불편해..

2. 대체 뭐하는 녀석이람?

위 얘기랑 이어지는 이야기일 수도 있는데 해당 클래스가 하는 일이 숨겨져(?) 있다보니, 대체 어떤 일을 하는 지 눈치 채기가 쉽지 않습니다. 작명을 잘 해줘야겠죠.

3. 핵심 로직은 눈에 확 들어올 듯.

AJ 파일로 빼내는 로직들은 대부분 공통적인 내용일 겁니다. CRUD가 대부분이고 ROO의 경우에는 finder도 제공해주겠죠. 즉 감춰져 있는 부분이 무엇인가를 명확히 인지하고 있다면, 그 뒤에는 핵심 로직만 작성하면 될테고 코드에서 확 들어나게 되어 있겠죠. 이렇게 되면 2번에서 대체 뭐하는 녀석인가?라고 고민하는 시간도 줄어들테지요.

4. 코드 네비게이션 불편.

역시나 AJDT가 개선해 주길 바라지만, 현재로서는 AspectJ로 추가한 메서드나 필드로 Ctrl + 클릭으로 이동하는 것이 안 됩니다. 툴 측면에서 보면 1번과 비슷한 불편사항으로 볼 수 있겠습니다.

5. 성능?

AspectJ를 사용해서 컴파일 시점에 위빙을 하면 런타임 시에 성능 문제는 거의 없겠지만, 이 컴파일 작업이 매번 테스트를 돌릴 때 마다 일어나기 때문에 일반적인 테스트를 돌리는 것 보다는 조금 오래 걸리는 것이 사실입니다. 하지만 뭐 그정도 차이는 무시할만 하더군요.

오늘의 결론..

툴 지원이 조금만 더 보완된다면, AspectJ를 활용한 코드젠과 프레임워크를 활용하여 좀 더 깔끔하고 유연한 코딩을 즐길 수 있을 것으로 예상 됩니다. 코드 자동 완성과 네비게이션이 불편한 지금도 만약 AspectJ로 추가한 코드에 접근 할 필요가 없다는 가정을 한다면, 해볼 만 하다고 생각합니다.

Roo처럼 콘솔까지 제공하고, 변경 사항을 트래킹하여 롤백한다거나 코드젠 이후에 직접 코드를 수정해도 유기적으로 반영해주는 기능을 구현하긴 힘들겠지만, 단순한 코드젠으로 AspectJ를 생성하고 이 AspectJ가 (OSAF 같은) 프레임워크 코드를 이용하도록 한다면, 기존의 프레임워크를 한 단계 업그레이드 할 수 있는 방안이 되지 않을까 생각합니다.

ps: 흠.. 일주일을 쉬고 왔더니 머리가 빙빙 도네요. 색시한테 9까지 간다고 했는데, 9시에 출발하겠네.. 쏘리 쏘리 쏘리 쏘리~
top


[AspectJ] Extension and Implementation

AOP : 2009.06.08 20:16


http://www.eclipse.org/aspectj/doc/released/progguide/semantics-declare.html#extension-and-implementation

    declare parents: EmpDao extends GenericDao<Emp, EmpParams>;
    declare parents: EmpDaoImpl extends HibernateGenericDao<Emp, EmpParams>;
    declare @type: EmpDaoImpl: @org.springframework.stereotype.Repository;

EmpDao 클래스가 GenericDao 클래스를 상속 받도록 설정.
EmpDaoImpl 클래스가 HibernateGenericDao 클래스를 상속 받도록 설정.
EmpDaoImpl 클래스에 @Repository 애노테이션 추가.

문법이 복잡해 보였는데 막상 사용해보니 간단 간단 하네요.

public interface EmpDao {

}

public class EmpDaoImpl implements EmpDao {

}

이런 기초적인 코드만 존재하지만..

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"/applicationContext.xml", "/applicationContext-datasource.xml"})
@Transactional
public class EmpDaoImplTest {

    @Autowired
    EmpDaoImpl daoImpl;

    @Test
    public void daoInterface() throws Exception {
        assertNotNull(daoImpl);
        daoImpl = new EmpDaoImpl();
        GenericDao<Emp, EmpParams> gdao = daoImpl;
        HibernateGenericDao<Emp, EmpParams> hgdao = daoImpl;
    }

    @Test
    public void crud() throws Exception {
        Emp emp = new Emp();
        daoImpl.add(emp);
        daoImpl.flush();
        assertEquals(1, daoImpl.getAll().size());
    }

}

이런 테스트를 돌릴 수 있다는거...



top


[AspectJ] privileged aspect

AOP : 2009.06.08 17:24


public class Emp {

    private String name;

    private String email;

}

이런 클래스가 있습니다. 이게 전부입니다.

public class EmpTest {

    @Test
    public void javaBean() throws Exception {
        Emp emp = new Emp();
        emp.setName("keesun");
        assertEquals("keesun", emp.getName());
        emp.setEmail("keesun@email.com");
    }

}

이런 테스트가 돌아갈까요? 훗.. 그럴리가요. 있지도 않은 메서드(게터, 세터)를 마구 썼는데 될리가 없죠. 그러나..  잘 돌아갑니다.


어떻게 된걸까요? privileged aspect를 사용하면 타겟의 private 또는 protected 멤버에도 접근할 수 있습니다.

http://www.eclipse.org/aspectj/doc/released/progguide/semantics-aspects.html#aspect-declaration

스프링 AOP로 이런 일을 하려면 Introduction을 사용 해야겠는데.. 그게 참.. 그리 쉽지 않았던 기억이 납니다. 하지만 AspectJ로는 간단하네요~

privileged aspect EmpAspect {

    //JavaBean
    public String smdis.model.Emp.getName() {
        return this.name;
    }

    public void smdis.model.Emp.setName(String name) {
        this.name = name;
    }

    public String smdis.model.Emp.getEmail() {
        return this.email;
    }

    public void smdis.model.Emp.setEmail(String email) {
        this.email = email;
    }

}

이렇게 추가할 메서드를 넣어주고 마치 자기가 가지고 있는 변수처럼 사용하면 됩니다.
top


스프링 AOP에서 this와 target 포인트컷 표현식 구분 하시는 분?

Spring/Chapter 7 : 2008.11.05 11:42


Pro Spring 2.5에서 this 표현식에 대한 정의입니다.

the semantics of the this pointcut are such that it would match any method execution on an object whose class matches the specified expression, but how could we match any class in the com package and its subpackages? Therefore, the only allowed syntax is this(class-name),

Pro Spring 2.5에서 target 표현식에 대한 정의 입니다.

Because the target expression defines a pointcut that would match execution of any method on an object whose class matches the specified expression, we cannot use the wildcards.

뭐가 달라 보이나요??? 앞 부분에 어순이 약간 바뀐것 빼고는 도무지 차이를 알 수가 없습니다.

레퍼런스를 보죠.

this - limits matching to join points (the execution of methods when using Spring AOP) where the bean reference (Spring AOP proxy) is an instance of the given type

target - limits matching to join points (the execution of methods when using Spring AOP) where the target object (application object being proxied) is an instance of the given type

레퍼런스는 그나마 좀 차이가 보입니다. this일 때는 프록시 객체고 target 일 때는 프록시를 적용할 타겟 객체가 주체가 됩니다.

즉, this 표현식은 주어진 타입에 해당하는 스프링 AOP Proxy의 조인포인트에 대응하는 표현식이고.. target 표현식은 주어진 타입에 해당하는 타겟 객체의 조인포인트에 대응하는 표현식이라는 것인데..

어차피 프록시 객체의 타입이 곧 타겟 객체의 타입과 동일하기 때문에 결과는 똑같을 것 같은데 말이죠. 차이를 모르겠습니다. 아흐.. 머리야..

마지막으로 AspectJ 문서를 보겠습니다.

this(Type or Id)
    Picks out each join point where the currently executing object (the object bound to this) is an instance of Type, or of the type of the identifier Id (which must be bound in the enclosing advice or pointcut definition). Will not match any join points from static contexts.

target(Type or Id)
    Picks out each join point where the target object (the object on which a call or field operation is applied to) is an instance of Type, or of the type of the identifier Id (which must be bound in the enclosing advice or pointcut definition). Will not match any calls, gets, or sets of static members.

this는 동적이고 target은 정적으로 타입을 지칭하는 차이밖에 없어보입니다. 흠.. 과연..

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="applicationContext.xml")
public class FooAspectTest {

    @Autowired
    FooBean fooBean;

    @Test
    public void isProxy(){
        assertTrue(fooBean instanceof Advised);
        fooBean.hi();
    }

}


@Aspect
public class FooAspect {

    @Pointcut("this(org.opensprout.spring.aop.thisandtarget.FooBean)")
    public void thisPointcut(){}

    @Before("thisPointcut()")
    public void say(){
        System.out.println("this pointcut executed.");
    }

}

스프링 AOP에서는 this를 target으로 고쳐도 똑같이 동작합니다. 콘솔에 메시지가 한 번 출력되죠. 그러나 AJDT로 실행하면, this의 경우 같은 메시지가 세 번 찍히고, target의 경우 같은 메시지가 네 번찍힙니다. 일단 두 번은 클래스 로딩이나 생성자 호출 조인포인트에서 찍혔다고 생각하고, 하나는 테스트에서 hi 호출 할 때 찍힌거고 가장 의아한건 target 표현식일 때의 마지막 한 번.

디버깅을 돌려본 결과 저 테스트에 두 번 들어가던데;; 왜 그런지 몰겠네요. 아~ 미궁이로 구나..
top


AspectJ의 @DeclareError를 사용해서 컴파일 시점에 아키텍처 에러 검증하자.

AOP : 2008.10.21 11:26


참조: http://www.parleys.com/display/PARLEYS/Home#slide=1;title=Spring%20Architectures;talk=20676612

위 발표자료 내용 주에 아주 잼나는 코드를 건졌습니다. 지난 번 KSUG에서 발표한 내용과 겹치는데 아래 코드는 그때 제가 보여드린 코드보다 좀 더 좋은 것 같아서 가져왔습니다.

@Aspect
public class SystemArchitecture {
  @Pointcut("execution(* configurator.*.*(..))")
  public void configuratorLogic () {}
  @Pointcut("execution(* dao.*.*(..))")
  public void dao() {}
  @Pointcut("within(*.dao.*)")
  public void inDaoLayer() {}
  @Pointcut("call(* *.service.*.*(..))")
  public void callServiceLayer() {}
}


@Aspect
public class Layering {
  @DeclareError("SystemArchitecture.inDaoLayer() && "+
   "SystemArchitektur.callServiceLayer() ")
  public static final String DAOsNotFromServices =
   "DAO must not call Service!";
 @DeclareError(" (call(* java.sql.*.*(..)) && " +
  "!within(*.dao.*) ) ")
  public static final String JdbcOnlyInDAOs =
   "JDBC only in DAOs!";
}

좋은 건 이Aspectj를 사용하면 @DecalreError를 사용해서, 컴파일 시점에 아키텍처 에러를 검증할 수 있다는 것입니다. 제가 준비했던 코드는 cflow를 사용해서 런타임에 검증하는 방법이었습니다. 따라서 테스트 하지 않고 그냥 커밋하면 뭐 어떻게 찾아낼 방법이 없었습니다. 그런데 이 방법을 쓰면 코딩할 때 문제되는 코드를 발견할 수 있으니 훨씬 좋은 것 같습니다. 캬.. 귿..


top


AspectJ와의 연동을 고려한다면, 포인트컷을 최소화 해야합니다.

AOP : 2008.10.08 16:37


무슨 이야기냐면, 최소 권한 원칙인가... 그런거랑 비슷한겁니다.

바로 예제를 보면서 살펴보죠.

@Aspect
public class HibernateExceptionToDataAccessException {

    @Pointcut("@within(org.springframework.stereotype.Repository)")
    public void accountHibernateExceptionInDao(){}

    @AfterThrowing(pointcut="accountHibernateExceptionInDao()", throwing="e")
    public void translateHibernateException(HibernateException e){
        throw SessionFactoryUtils.convertHibernateAccessException(e);
    }

}

이 애스팩트는 하이버네이트 예외를 스프링의 DataAccessException으로 변환해주는 애스팩트입니다. 이 녀석은 하이버네이트로 DAO 만드는 여러 방법 중에 가장 깔끔한 방법을 사용할 때 쓰면 좋고 안 써도 별로 상관없는(하이버네이트 버전이 올라가면서 하이버네이트 예외도 uncatched exception으로 바꼈으며 계층 구조도 세밀하게 나눠뒀기 때문입니다.) 그런 애스팩트입니다. 그래도, 버전 올리기 힘든 하이버 예전 버전을 사용하는 라이브러리를 사용해야 한다면 유용하겠죠.

어쨋든, 본론으로 돌아가서..

저렇게 만들어둔 애스팩트에 문제점이 보이나요? 저도 방금전까진 몰랐습니다. 일단, 저 애스팩트의 포인트컷은 이해가 가시죠? @Repository 애노테이션을 가지고 있는 클래스의 모든 조인포인트를 나타낸 겁니다.

문제는 바로 이 조인포인트.. 이게 핵심입니다. 스프링에서는 메소드 실행 조인포인트만 사용하기 때문에, 저 애스팩트를 스프링 AOP에서 사용할 땐, 원하던 메소드에만 적용이 될 겁니다. 하지만, 만약 저 애스팩트를 AspectJ와 연동해서 사용한다면? 어떤 일이 벌어질까요?

사용자 삽입 이미지

캬오.. 43개??? 말도 안돼. 내가 테스트 할려고 만든 DAO가 몇개나 된다고.. 그 안에 메소드도 거의 한 두 개밖엔 안만들었는데.. 왠 43개.... 바로 크로스 레퍼런스 뷰를 열고 확인해봤습니다.

사용자 삽입 이미지

캬오~~~~ 마이 미스테이크... 처방이 필요합니다. 처방은 간단하기 때문에 비밀! 캬캬캬.(이번주 KSUG 세미나에서 공개하도록 하죠.) 처방후에는..

사용자 삽입 이미지

이렇게 AspectJ에서도 메소드 실행 조인포인트에만 걸 수 있습니다. 음하하하..
top


AspectJ로 final method에도 위빙하기

Spring/Chapter 6 : 2008.10.02 10:03


소스 코드는 이전과 동일합니다. 그 상태에서 프록젝트에 AspectJ Nature를 추가해줍니다.

사용자 삽입 이미지

그런 다음에 프로젝트 클린을 하여 기존의 클래스파일을 비우고 다시 컴파일하게 합니다.(Alt + P, N, 엔터) 지금, 저는 아무런 .aj 파일도 만들지 않았습니다. 그냥 이전에 만들어둔 Spring @AOP를 사용하고 있을 뿐입니다.

@Aspect
public class FinalHelloAspect {

    @Before("execution(* org.opensprout.sandbox.proxy.withfinal.FinalHello.*(..))")
    public void withFinalAdvice() {
        System.out.println("before advice from FinalHelloAspect");
    }

}

이 녀석이죠. AspecJ 프로젝트가 됐기 때문에, 빌드타임에 저 애스팩트의 포인트컷에 해당하는 클래스 파일을 조작해서 "새로운 .class 파일"을 생성하게 될 겁니다.

사용자 삽입 이미지

컴파일이 끝난 후 AspectJ IDE가 발동한 모습이니다. 포인트컷 마다 저런 화살표가 표시됩니다. 보시면 final 메소드에도 화살표가 표시되어 있습니다. 해당 코드와 Cross References 뷰를 동기화 시켜두면, 해당 지점에 적용될 어드바이스까지 표시됩니다.

사용자 삽입 이미지

놀랍습니다. 안 그러세요? @Aspect 캬오~ 하긴, 그리 놀랍지도... @Aspect 애노테이션이 aspectj 프로젝트에 속한 애노테이션이니까,..

사용자 삽입 이미지

이 결과를 보면 더이상 프록시를 사용하고 있는것이 아니기 때문에, Advised 라는 인터페이스는 사용할 수 없다는 것을 볼 수 있습니다. ClassCastException이 보이시죠?

흠냐;;

회사 청소해야되서 이만.. 황급히 마무리 합니다.
top


TSE 2006(Applying Domain Design in the Enterprise with AspectJ)

Spring/TSE 2006 : 2007.12.06 09:27


AspectJ In Action의 저자답게 AspectJ로 DDD를 돕는 여러가지 방법을 설명해줬습니다.

• Overview of Domain-driven design
• Aspects for crosscutting infrastructure
• Aspects for fine-grained DI
• Aspects for domain logic
• Aspects for enforcing DDD best
practices
• Proceeding towards DDD

이런 순서대로 발표가 진행됐는데, 토비님께서 마소에 기고하셨던 내용과 비슷한 내용들이 초반에 언급되었고 그 뒤로는 AspectJ를 사용하여 DDD 구현에 도움이 되는 방법들을 소개해 줬습니다.
  1. Service Layer에서 Aspect성 기능들을 Aspect로 구현하기.
  2. Aspect 사용해서 Repository나 Facade나 Service 객체들을 도메인에 DI 하기.
  3. 도메인 로직 중에 Aspect성 기능들을 Aspect로 구현하기.
  4. 아키텍처 정책을 수행하도록 강제하는 기능들을 Aspect로 구현하기.(web에서 Repository 호출하면 Eclipse에서 error로 표시하도록, DI사용해서 주입해야 할 것들을 명시적으로 new 하지 못하도록, ...)
마지막으로 다음과 같은 '사고의 흐름'을 권장해줬습니다.

• 도메인 엔티티와 도메인 로직부터 시작하기
– Basic domain-driven and object-oriented principle
• 시작할 때 기본적으로 service 계층은 없다고 생각하기
– See how far you can get
– Add service level as required
• 구현과 관련된 규칙들을 강제하기
• DDD로 리팩터링하기.
top


휴.. Spring AOP와 AspectJ 연동 성공



이전 글의 예상이 맞았습니다.

AspectJ 파일(aj 확장자)을 ajc라는 것으로 컴파일을 해야 하는데 이 녀석을 Eclipse에서는 어떻게 컴파일 할 지 모르기 때문에 컴파일을 못해서 class 파일이 없으니까 결국 Spring 컨테이너는 class 파일이 없어서 AspectJ로 작성한 Aspect를 못 읽어 들이고 에러를 내고 만 것이였습니다.

해결책은 ajc 사용해서 컴파일 해도 되겠지만.. 커맨드 라인에서 무언가를 하는것이 상당히 귀찮은 저 같은 분들은 AJDT 플러그인을 설치하시면 됩니다.

AJDT 홈페이지에 가시면 Eclipse 버전에 따라 release 정보가 표시되어 있습니다.

저는 Eclipse 3.3을 사용하기 때문에 다음의 URL로 업데이트 사이트를 등록하고 플러그인을 설치했습니다.
http://download.eclipse.org/tools/ajdt/33/update

설치한 뒤 해당 프로젝트에 "Convert to AspectJ Project"를 실행해주면 aj 파일은 ajc 사용해서 자동으로 컴파일 해주고, aspecjrt.jar 파일을 클래스패스에 추가해 줍니다.

사용자 삽입 이미지

그럼 Advice가 적용되는 지점에 해당 Advice가 몇 개 적용되는지 보여 줍니다.
사용자 삽입 이미지

멋진 툴입니다.

Class를 못찾던 문제도 해결 됐고 Spring AOP와 AspectJ를 연동도 간단하게 해결되었습니다.
top


Aspect-Oriented Programming with Spring AOP and AspectJ



Interface 21의 아드리안이 발표한 PPT인것 같습니다. 구글에서 "spring aop aspectj"로 검색했더니 나왔습니다. 굉장히 멋진 발표였을 것 같은데 중간 중간 데모를 못보는 것이 너무 아쉽습니다.

Spring AOP에서 AsepctJ와 연동하는 부분이 막혀서 구글링을 하던 중이였는데 AspectJ의 aj 파일을 컴파일 해서 class 파일로 만들어야 할 것 같습니다. 안그러면 Spring 컨테이너에서 Bean으로 읽어 들일 때 ClassNotFoundException이 떨어지게 됩니다. 물론 그걸 Spring이 잡아서 CannotLoadBeanClassException이라고 좀 더 명확하게 이야기를 해줍니다.ㅋ

2006년 7월에 PPT 파일명을 보니.. Free Seminar... Interface 21에서 무료 세미나도 해주나 봅니다. 우워..... 부럽..
지만 한국에는 KSUG가 있죠.

top


Eclipse에서 AspectJ 개발 동영상입니다.

AOP : 2007.02.15 17:46



JCO에서 하는 DevEnv UCC에 올린 동영상입니다. AJDT를 사용해서 간단한 AspectJ 샘플을 만들어 봤습니다.

참조 : http://www.eclipse.org/ajdt/demos/


top


AspectJ 다운로드 & 이클립스 플러긴 설치

AOP : 2007.01.05 21:43


AspectJ 다운로드 : http://www.eclipse.org/aspectj/downloads.php

AspectJ Development Tools(AJDT) 다운로드 : http://www.eclipse.org/ajdt/downloads/

사용자 삽입 이미지
AJDT 압축 파일을 보면 plugins와 features 디렉토리가 보입니다. 위 폴더는 각각 [eclipse가 설치된 폴더]/plugins 와 [eclipse가 설치된 폴더]/features 에 풀려야 합니다.

압축 파일 말고 Eclipse -> help -> Software Update - find and install 메뉴를 사용하실 분들은 다음의 주소를 이용하면 됩니다.
http://download.eclipse.org/tools/ajdt/32/update
top