Recommended
More Related Content
Similar to [스프링 스터디 3일차] AOP와 LTW
Similar to [스프링 스터디 3일차] AOP와 LTW (20)
More from AnselmKim
Recently uploaded
Recently uploaded (7)
[스프링 스터디 3일차] AOP와 LTW
- 1. AOP와 LTW
- 2. 프록시 기반 AOP 종류 설명 장점 비고 AOP 인터페이스 구현과 <bean> 등록을 이용하는 방법 AOP 구성요소를 모두 클래스로 개발하고 그 것을 빈으로 등록해서 적용하는 방법 AOP가 어떻게 동작하고 적용되는 지를 이해하기에는 가장 쉽다 가장 오래되고 원식적인 방법 AOP 인터페이스 구현과 AOP 네임 스페이스의 <aop:advisor>를 이용 하는 방법 포인트컷 표현식을 적극 활용해서 포인트컷 과 어드바이저, 자동프록시 생성기 빈 등록을 aop 스키마의 간결한 전용 태그만으로 가능 하게 하는 방법 <bean> 태그를 이용하는 방법보다 설정은 단순해지고 이해하기도 쉽 기 때문에 빈을 직접 등록하는 방 법을 대신해서 자주 사용 aop 스키마의 전용 태그를 이용했 을 뿐 내부적인 빈의 구성과 동작 방식은 첫번째와 다를 바 없다. 임의의 자바 클래스와 AOP 네임스 페이스의 <aop:aspect>를 이용하 는 방법 AOP 네임스페이스를 사용하지만 기존의 어 드바이스, 어드바이저 개념 대신 애스팩트라 는 개념을 이용 <aop:aspectj> 태그를 이용해서 평범한 자바 클래스를 AOP 애스팩트로 만들 수 있다. 애스팩트는 특정 인터페이스를 구현할 필요 가 없다. 인터페이스를 구현하는 제약조건 이 없으므로 메소드는 유연하게 정 의 하나의 클래스 안에 여러개의 애스 팩트를 포함 할 수있다. @AspectJ 애노테이션을 이용한 애스팩트 개발 방법 Aspect AOP 프레임워크에 정의된 애노테이 션을 이용해 애스팩트를 만들 수 있는 것 스프링의 프록시 기반 AOP를 만들 때 사용 어드바이스와 포인트컷은 자바 클래스 내에 정의한 애노테이션을 이용해 정의 AOP의 구성요소를 애노테이션을 이용해 정의할 수 있게 해주기 때 문에 <aop:config>을 사용할 필요 가 없다. @AspectJ 문법과 애스펙트 정의 방법을 차용했을 뿐 AspectJ AOP 를 사용한것은 아니다 프록시 기반 AOP 종류와 특징
- 3. 자동 프록시 생성기와 프록시 빈 스프링 AOP를 사용한다면 어떤 개발 방식을 적용하든 모두 프록시 방식의 AOP 프록시 개념은 데코레이터 패턴에서 나온것이고 동작원리는 JDK 다이내믹 프록 시와 DI를 이용 자동 프록시 생성기에 의해 만들어진 프록시와 빈처럼 수동으로 등록한 프록시의 차이점 자동 프록시 생성기가 만들어주는 프록시는 새로운 빈으로 추가되는 것이 아니라 먜 대상 타깃 빈 을 대체 결과만 본다면 수동이나 자동이나 프록시가 클라이언트와 타겟 사이에 DI를 통해 끼어들어서 부가 기능을 제공했기 때문에 똑같아 보일 수 있다. 하지만 등록된 빈의 관점으로 보면 자동에서는 타겟 오브젝트가 빈으로 직접 노출되지 않는다.
- 4. 자동 프록시 생성기와 프록시 빈 자동 프록시 생성기의 특징 1. AOP 적용은 @Autowired의 타입에 의한 의존관계 설정에 문제를 일으키지 않 는다. a. 직접 타깃 오브젝트의 인터페이스를 구현한 프록시를 적용한 경우에는 클라이언트가 @Autowired를 사용할 수 없다. b. 자동 프록시 생성기를 사용하는 프록시 AOP에서는 이런 문제가 발생하지 않는다. 2. AOP 적용은 다른 빈들이 Target 오브젝트에 직접 의존하지 못하게 한다. a. XML이나 애노테이션을 통해 빈으로 등록된 타겟 클래스를 프록시 안에 감춰버린다. b. 프록시는 근본적으로 타겟 클래스와 동일한 인터페이스를 구현해야 하므로, 프록시 빈은 인터
- 5. 자동 프록시 생성기와 프록시 빈 1. 이슈 : 타겟의 클래스 타입을 이용해 직접 의존하고 있던 빈이 있을 경우 자동 프록시 생성기에 의해 타겟 오브젝트가 프록시 빈 안에 숨어버리면 문제가 발 생 2. 타겟 클래스 타입의 빈을 찾지 못해 DI 할 수 없다는 예외를 내면서 컨테이너 초 기화 작업 중단 3. @Autowired 기본설정인 required=true를 false로 바꾸지 않았다면 빈 초기 화 에러 발생
- 6. 프록시의 종류 1. 아무런 인터페이스도 구현하지 않은 타깃 클래스에 AOP를 적용 a. 타깃 클래스 자체를 인터페이스처럼 사용 b. 클라이언트가 타깃 클래스에 의존하는것은 변하지 않음 c. 타깃 클래스를 상속한 서브 클래스를 만들어서 이것을 프록시로 사용 d. 프록시를 만들기 위해 클래스 상속 > public 메소드를 모두 오버라이드해서 프록시 기능으로 전 환 e. 제약 조건 i. final 클래스와 final 메소드에는 적용이 안되며 타깃 클래스의 생성자가 두 번 호출 됨 1. final 클래스는 상속을 할 수 없고 final 메소드는 오버라이딩이 불가능 하기 때문
- 7. 프록시의 종류 1. 강제로 클래스 프록시를 만들도록 설정하는 것 a. 클래스 프록시를 강제하면 인터페이스가 있더라도 무시하고 클래스 프록시를 만든다 b. aop 네임스페이스를 사용해 AOP를 설정했다면, <aop:config>의 proxy-target-class 애트리뷰 트를 true로 지정해주면 된다. a. 애노테이션 방식의 AOP인 @Transactional을 적용하기 위한 <tx:annotation-driven> 태그에도 proxy-target-class=”true”로 설정해주면, 인터페이스의 존재와 상관없이 클래스 프록시가 만들 어진다.
- 8. @Aspect AOP 애스팩트 애플리케이션의 도메인 로직은 담은 핵심 기능은 아니지만, 많은 오브젝트에 걸쳐서 필요한 부가 기능을 추상화해놓은 것 구조적으로 하나 이상의 포인트컷과 어드바이스로 구성 예를 들어 스프링의 어드바이저는 가장 단순한 형태의 애스팩트라고 볼 수 있다 독립적인 빈의 조합으로 만들어지는 어드바이저와 달리 하나의 모듈에서 다양한 조합을 갖는 포인 트컷과 어드바이스를 정의할 수 있다.
- 9. @Aspect 클래스와 구성요소 자바 클래스에 @Aspect 애노테이션을 붙여서 만든다 @Aspect로 만든 클래스에는 포인트컷과 어드바이스를 애노테이션이 달린 메소 드를 사용해 정의한다. 분류 애노테이션 설명 포인트컷 @Pointcut - @Pointcut 안에 포인트컷 표현식을 넣어서 정의 - 하나의 @Aspect 클래스 안에 여러 개의 포인트컷을 선언 가능 - ex) 어드바이 스 @Before @AfterReturning @AfterThrowing @After @Around - 다섯 가지 종류의 어드바이스를 사용할 수 있다. - 메소드 내의 자바 코드로 작성 - 나의 @Aspect 클래스 안에 여러개의 어드바이스를 선언 가능
- 10. 포인트컷 메소드와 애노테이션 1. 포인트컷은 @Pointcut 애노테이션과 메소드의 이름, 파라미터로 정의 됨 2. @Pointcut으로 정의된 포인트컷은 다른 포인트컷 또는 어드바이스에서 사용 된다 3. 여러종류의 포인터컷 지시자를 이용해 정의할 수 있음 4. 자세한 내용은 스프링 레퍼런스 매뉴얼의 ‘pointcut’ 항목을 참고 5. 포인트컷은 적용할 조인 포인트를 선별하는 것 6. 조인 포인트는 어드바이스로 정의도니 부가기능을 적용할 수 있는 위치 7. 포인트컷 설명에서 조인 포인트라고 하면 메소드를 가리킨다라고 이해하면 된
- 11. 어드바이스 메소드와 애노테이션 1. 어드바이스는 5가지 종류가 있는데 어드바이스를 쉽게 작성할 수 있도록 메소 드 실행 과정의 일부분에만 적용하도록 만든 어드바이스가 있기 때문이다. 2. 프록시를 통해 타깃 오브젝트가 호출되는 과정과 그 과정 중에 어드바이스를 적용할 수 있는 지점을 표현한 그림 1. 어드바이스가 프록시 안에서 어느 단계에 적용되느냐에 따라 어드바이스의 종 류가 달라지기때문에 다섯가지 어드바이스 애노테이션 중 하나를 선택해서 사 용 2. 모든 어드바이스 애노테이션은 기본값으로 포인트컷을 지정하도록 되어있다
- 12. @AspectJ를 이용한 AOP의 학습 방법과 적용 전략 AOP는 항상 단순하고 명료하게 접근하자 가능한 한 직관적으로 선정 대상을 파악할 수 있도록 포인트컷에 의미 있는 이름 을 부여하고 이를 조합해서 사용하는 습관을 들이자 객체지향적인 방법으로 해결할 수 있는 것을 불필요하게 AOP를 이용하려고 하지 말아야 한다. 과도한 AOP 적용은 애플리케이션 성능에 영향을 줄 수 있다
- 13. AspectJ AOP 가장 강력한 AOP 프레임워크 자바 언어 자체를 확장해서 만든 aspect 문법을 이용해 애스펙트를 작성해야 한 다. 스프링 AOP에서는 DI의 도움을 받아 프록시 오브젝트를 추가해서 애스팩트를 적 용 AspectJ는 타깃 오브젝트 자체의 코드를 바꿈으로써 애스팩트를 적용(프록시 사 용 X) 타깃 오브젝트의 자바 코드에 처음부터 애스팩트가 적용되어 있던 것처럼 클래스 바이트코드를 변경하는 작업이 필요
- 14. AspectJ AOP AspectJ AOP가 번거로운 클래스 파일의 바이트코드를 조작을 필요로 하는 이유? 프록시 방식으로는 어드바이스를 적용할 수 없는 조인 포인트와 포인트컷 지시자를 지원하기 위해 자바의 프록시 기법을 이용해서는 특정 오브젝트가 생성된 시점이나 특정 필드를 읽을 지점에 어드바이스를 추가할 방법이 없다. 이런 조인 포인트에 어드바이스를 추가하려면 조인 포인트 위치의 코드를 변경하 는 수밖에 없다. 그래서 AspectJ 는 복잡하지만 바이트코드 자체를 조작하는 방식을 선택 스프링 AOP와 AspectJ AOP를 동시에 적용하는 것은 피하는 것이 좋다.
- 15. 빈이 아닌 오브젝트에 DI 적용 도메인 오브젝트는 다른 빈을 참조하지 않기 때문에 DI를 받을 필요가 없다. 필요 시 새로운 오브젝트를 만들어야 하기 때문에 스프링컨테이너를 통한 싱글톤 관리를 할 필요도 없다 그렇기 때문에 빈 등록 대상이 아니다. 문제 : 도메인 오브젝트가 다른 빈을 사용하고 싶다면 어떻게 될까? 현상 : DI를 적용해야 하기 때문에 도메인 오브젝트를 스프링 빈으로 등록하고 IoC/DI가 적용되게 해야한다. 애플리케이션 코드에서만 생성한다면 가능하겠지만 하이버네이트, JPA, ibatis 등 프레임워크나 @MVC의 핸들러 어댑터 내부에서 도메인 오브젝트를 생성하는
- 16. 빈이 아닌 오브젝트에 DI 적용 해결 : AOP 적용 도메인 오브젝트가 생성되면 자동 DI작업을 수행해주는 어드바이스를 적용 적용 시 특정 오브젝트가 생성되는 지점에 자동으로 DI 기능을 가진 어드바이스 를 적용해야 하는데 오브젝트 생성은 스프링 AOP에서 지원하는 조인 포인트가 아니다 그렇기 때문에 AspectJ AOP의 기능을 이용한다.
- 17. DI 애스펙트 DependencyInjectionAspect라는 애스펙트를 제공 스프링에서 AspectJ 기술로 만들어서 제공 소스코드를 보더라도 AspectJ 문법이기 때문에 쉽게 이해하기 힘듬
- 18. DI 애스펙트 포인트컷
- 19. DI 애스펙트 어드바이스
- 20. 로드타임 위버와 자바 에이전트 DI 애스펙트를 사용하려면 두 가지 작업 필요 AspectJ AOP가 동작할 수 있는 환경설정이 필요 DI 애스펙트 자체를 등록해서 @Configurable 오브젝트에 어드바이스가 적용되도록 해야한다. AspectJ를 사용하려면 클래스 로딩 시점에 바이트코드 조작이 가능하도록 로드타 임 위버를 적용 로드타임 위버는 JVM의 javaagent 옵션을 사용해 JVM 레벨에 적용
- 21. 로드타임 위버(LTW) <context:load-time-weaver>는 단순히 @Configurable을 위해서만 사용하는 것 이 아니라 스프링에서 여러가지 기능에 활용 @Configurable 지원 <context:spring-configured />로 등록한 DI 애스펙트가 동작하도록 로드타임 위버 기능을 대신해준다. 트랜젝션 AOP의 모드를 AspectJ로 설정 했을 때 <tx:annotation-driven mode=”aspectj” />로 트랜잭션 AOP의 모드를 AspectJ로 설정 했을 때 AspectJ가 아니라 JPA에서 필요로 하는 로드타임 위버로 사용되는 것
- 22. 로드타임 위버(LTW) JPA는 대부분 로드타임 위버를 이용한 바이트 코드 조작을 필요로 한다. 도메인 오브젝트에 지연된 로딩이나 변경항목 감시, 그룹조회, JOIN을 이용한 로 딩 및 최적화 기능을 적용하려면 POJO 클래스의 바이트 코드를 조작해야 한다. 이것 때문에 각 구현 제품마다 전용 로드타임 위버를 제공 문제점 : AspectJ와 JPA의 로드타임 위버를 모두 적용해야 할때 자바에이전트는 JVM 레벨에 적용
- 23. 로드타임 위버(LTW) AspectJ와 JPA의 로드타임 위버를 모두 적용해야 하는 문제 해결 : 스프링의 로드타임 위버는 JPA와 AspectJ를 위한 로드타임 위버 기능을 대신해준다. JPA를 스프링의 LocalContainerEntitiyManangerFactoryBean을 이용해 설정 했다면 <context:load-time-weaver>를 추가하는 것만으로 스프링의 로드타임 위버가 자동으로 JPA와 AspectJ용 로드타임 위버로 동작한다. 자바에이전트는 JVM 레벨에 적용된다는 문제 해결 : JVM 레벨의 자바에이전트를 대체할 수 있는 로드타임 위버 적용 방법을 자동으로 찾아줌 스프링의 로드타임 위버는 자바에이전트 방식에 종속적이지 않음 <context:load-time-weaver>설정은 현재 애플리케이션의 환경 정보를 분석해서 그에 적합한 로 드타임 위버를 등록
- 24. Thank you
Editor's Notes
- 이니셜라이제이션과 컨피그 new 키워드는 또는 리플렉션에 의해 생성자가 호출되어 오브젝트가 생성되는 지점을 가리킨다. ConfigurableObject가 생성될때 초기화 지시자를 적용한 포인트컷이다. ConfigurableObject는 이 코드 같이 정의가 되어 있는데 잘 보면 @Configurable이 붙은 클래스의 생성자가 호출돼서 오브젝트가 만들어질 때를 가리키는 포인트 컷이라고 할 수 있습니다.
- 앞에서 정의한 포인트컷인 beanConstruction()과 몇가지 조건이 결합해서 이 어드바이스가 실행되고 있습니다. @Configurabledㅣ 붙은 오브젝트가 생성되는 조인 포인트에 이 어드바이스가 실행 되도록 되어있다 DependencyInjectionAspect 애스펙트가 적용되면 @Configurable이 붙은 도메인 오브젝트가 어디서든 생성될 때마다 이 어드바이스가 적용되어 자동 DI 작업이 일어난다.