5. AOP와LTW

5. AOPDHK LTW(로드타임 위빙)

5.1 애스펙트 AOP

프록시 기반 AOP

스프링은 JDK 동적 프록시를 이용하여, 바이트 코드 조작없이 유용한 AOP 기능을 제공 데코레이터 패턴과 프록시패턴의 응용의 산물... Pointcut과 자등프록시생성(Advice+Pointcut 조합) => AOP기능 구현

• 가장 기초적인 프록시 AOP 개발 AOP에 참여하는 구성요소 (포인트컷, 어드바이스)를 클래스 작성 -> Bean 등록 어드바이스와 포인트컷은 M:N 으로 적용될 수 있다. 간단한 AOP 기능은 빈 클래스 구현과 빈 등록으로 구현이 충분히 가능 1. 포인트컷 : 클래스 작성 -> 빈 등록 : 스프링은 AspectJ의 표현식 차용 -> AspectJExpressionPointcut 사용 2. 어드바이스 : 클래스 작성 -> 빈 등록 3. 포인트컷 + 어드바이스 = 어드바이저 : 빈등록된 어드바이스 + 포인트컷 -> 어드바이저 빈등록 4. 자동프록시생성기 : 어드바이저 -> 자동프록시 생성기 빈에 등록

• AOP 인터페이스 구현과 aop 네임스페이스의 <aop:advisor> 태그를 이용하는 방법 어드바이스는 Adivce 인터페이스를 구현하는방식 포인트컷, 어드바이저, 프록시자동생성기 -> 빈 등록 -> aop스키마의 전용 태그만으로.. <bean>등록보다 간결하고 명확하기 때문에 자주사용하는 방식

  • <aop:advisor> : 어드바이스 빈 참조 + 포인트컷 작성 or 포인트컷 참조 등록

  • <aop:pointcut> : 포인트컷 -> 따로 독립적구현 가능. 종속적으로 어드바이저에 매핑 가능

  • <aop:config> : 자동프록시생성기 빈에 해당

• 임의의 자바 클래스와 aop 네임스페이스의 <aop:aspect>를 이용하는 방법 2번째와 동일하게 aop 스키마를 사용하며, 기존의 어드바이스, 어드바이저 개념 대신 aspect개념을 이용 스프링은 OOP 개념으로 접근을하여 프록시전략을 활용하여 AOP를 구현중 ... 그러나 AspectJ의 확장언어를 지향하는 AOP에서는 애스펙트라는 AOP 모듈을 정의하는 방법을 이용 애스펙트는 기본적으로 일반 자바 클래스를 이용하여 정의 할 수 있지만, 특정 인터페이스를 구현할 필요가 없이 그냥 1.애노테이션, 2.XML의 aop:aspect 태그를 이용하여 자바클래스 -> AOP 애스펙트로 만들 수 있음

• @Aspect 애노테이션을 이용하는 애스펙트 개발 방법 @AspectJ는 이름 그대로 AspectJ AOP 프레임워크에서 정의된 애노테이션을 이용한다. 하지만 @AspectJ 문법과 애스펙트 정의 방법만 차용 했을 뿐 AspectJ를 사용하는 것은 아니다. 즉, @AspectJ 애노테이션 방식도 스프링의 프록시 기반 AOP를 사용한다. @AspectJ가 AspectJ를 사용하는 것이 아님을 주의

첫번째 방식이 가장 구식이므로 실전에서는 사용을 배제하고, 2,3,4번째에서 사용하기를 권장한다. XML은 2,3번 / 애노테이션은 4번 2번째 같은 경우 Advice 인터페이스를 구현하여 어드바이스를 이용 (스프링의 트랜잭션 AOP는 이방법을 사용함) 3번째 같은 경우 애스펙트 방식인데, 좀 더 유연하게 AOP를 적용할 수 있다. (단점은, 디버깅의 어려움, 러닝커브) -> 보통은 이방식을 채택한다

결론

XML -> 3번째 (aop:aspect) 애노테이션 -> 4번째 (@Aspect) 포인트컷 -> AspectJ 표현식을 사용하는게 가장 편리 (execution, bean, anotation 등) Spring AOP -> 어떤 방식을 사용하든 프록시 기반의 AOP이라는 점 유의 Spring의 프록시 개념 -> 데코레이터 패턴에서 나온것이고, 동작원리는 JDK 동적 프록시와 DI 이용 Client -> Target을 호출할 때, Client -> Proxy -> Target (프록시가 관여하여 가로챔)

프록시 기반으로 구현될 경우 @Autowired로 Target에 주입할 때 문제가 되는데, 그 이유는 Target에 해당하는 인터페이스의 구현체가 2개 이상일 수 있기 때문이다.

그렇다면 자동프록시 생성기법으로..? 컨테이너 초기화때 등록된 빈들을 로딩 -> 이때 프록시를 자동생성하여 등록 -> 빈선택은 포인트컷이.. / 빈 후처리기를 사용하여 정의된 빈의 의존관계 바꿔치기

수동으로 등록한 프록시 빈과 자동프록시생성의 차이 수동 : 빈에 직접등록, 타깃, 프록시 자동 : 빈으로 등록된 타겟을 자기가 대체함. 프록시 빈 등록하지 않음 (빈이 직접적으로 노출되지 않는다는 점이 다름) -> @Autowired 사용에 따른 에러가 발생하지 않게 된다 -> 프록시는 근본적으로 타겟과 동일한 인터페이스를 구현하게 되는데, 이때 프록시빈은 상위타입인 인터페이스의 타입을 갖게 될 뿐, 구현체의 타입을 갖지는 않는다. 따라서 자동생성되서 대체되는 프록시 빈은 Interface 타입일 뿐 Target 타입은 아니다. 클라이언트가 인터페이스 타입을 사용하기 때문에 문제가 되지는 않지만, 하위타입인인 구현체를 사용할 경우 DI 기술에 대한 문제는 없으나, 자동프록시에 의해 그 타겟이 프록시빈으로 감춰지게 되면 컨테이너 초기화 과정에서 예외가 발생하게 된다.

프록시

1. 프록시 생성을할 때, 타깃이 인터페이스를 구현하고 있다면, 프록시는 그 인터페이스 타입을 갖게 되지만, 인터페이스를 구현하지 않고 있다면 CGLib를 이용한 클래스 프록시를 만든다.

2. 강제로 클래스 프록시를 만들도록 할 수 있다. (1번에서 후자) 클래스 프록시를 강제 하면 -> 인터페이스가 있더라도 무시하고 클래스를 프록시로 만든다 -> aop 스키아 사용시 aop:config에서 proxy-target-class="true"로 설정을 하면 된다.

   <aop:config proxy-target-class="true">
   ...
   </aop:config>

   애노테이션 AOP 방식의 @Transactional -> <tx:annotation-driven>에도 proxy-target-class="true"를 주면 인터페이스의 존재와 상관없이 클래스 프록시를 생성. 이때 프록시의 타입은 타깃오브젝트의 타입과 동일하다

@AspectJ AOP

Aspect란, OOP의 클래스와 비슷한 개념이라고 생각하면 쉽다. 그 자체로 핵심기능은 아니지만 많은 오브젝트에 걸쳐서 필요한 부가기능을 추상화 해놓은 것. Aspect는 하나이상의 포인트컷과 어드바이스로 구성된다. 스프링의 Advisor는 하나의 포인트컷과 하나의 어드바이스 조합으로, 가장 단순한 Aspect라고 생각할 수 있다.(Aspect>Advisor) @AspectJ -> Aspect를 자바클래스, 메서드, 애노테이션 이용하여 정의하는 방법

1. <aop:aspectj-autoproxy> 설정 사실 @AspectJ 애노테이션은 존재하지 않는다. @AspectJ 방식의 애스펙트를 사용하려면 XML 설정파일에 저 위에 태그를 선언해줘야함 이 선언은 빈으로 등록된 클래스 중에서 클래스 레벨에 @Aspect 애노테이션이 붙은 것을모두 애스펙트로 자동등록 해준다. 핵심이다.

2. AspectJ 런타임 라이브러리를 클래스패스에 추가

3. @Aspect @Configuration 처럼 클래스에 선언하여 마킹. 이 클래스가 어떤 하나의 애스펙트 임을 마킹한다. 그리고 Aspect로 마킹된 클래스는 빈으로 등록되어야 한다.

4. @Pointcut @Bean 처럼 메소드에 마킹한다. 마킹 된 메서드는 하나의 포인트컷으로 작용. @Pointcut(표현식) 을 통해 선택 알고리즘을 지정함. 여러개의 포인트컷을 선정해놓고 활용 할 수 있다.

5. Advice(@Before, @After, @AfterReturninig, @AfterThrowing, @Around) 조인포인트에 따른 5가지의 어드바이스를 설정 할 수 있다. 평범한 POJO클래스로 구현하면 됨

포인트컷 메서드와 애노테이션

@Pointcut, 메서드 이름, 파라미터로 정의 메서드의 리턴타입 : 항상 void형 메서드의 이름 : 포인트컷의 이름으로 사용 됨

@Pointcut("execution(* sayHello(..))")
private void hello();

포인트컷은 또 다른 포인트컷이나 어드바이스에서 활용될 수 있으며, 포인트컷이 참조 될 때 메서드이름+파라미터까지 포함한다.

• execution()

  가장 대표적. 접근제한자, 리턴타입, 타입, 메서드, 파라미터 타입, 예외타입 6개 -> 리턴타입, 메서드, 파라미터 3개는 필수

• within()

  타입만. 간편하게 사용해야 할때 좋음. 패키지까지 선택 가능

  A.B.C.., A.B.C. 등

• bean() 빈 이름 or 아이디를 이용. 와일드카드(*) 사용가능. AspectJ에서 차용한게 아니며, Spring AOP 전용지시자.

• this, target, args,

• @target, @within, @args, @annotation

• &&, ||, ! 논리연산자로 조합 가능.

어드바이스 메서드와 애노테이션

5가지의 종류가 있다

정상, 검사예외처리 : Around -> Before -> 타겟 메서드 -> Around -> After -> After Returning 예외 : Around -> Before -> 타겟 메서드 -> After -> After Throwing

• @Around 포인트컷에서 전후 처리. 다양한 조작이 가능하나, 그만큼 작성하기 복잡 나머지 어드바이스를 검토하고, 없을 경우에만 최후의 선택이 바람직. ProceedingJoinPoint를 파라미터로 선언하여 타겟메서드에 대한 정보를 취득 할 수 있다. proceed 메서드를 실행할 때, 매개변수에 전달인자의 배열을 넘기면 타겟메서드 실행시점에 변경된 인자값을 넘길 수 있다.

• @Before 타겟메서드 실행전에 실행되는 어드바이스다. JoinPoint 인터페이스를 파라미터로 선언하여 타겟 메서드의 정보를 취득 할 수 있지만, 실행은 할 수 없다(proceed()).

• @AfterReturninig 정상종료 된 이후에 호출 되기 때문에 메소드의 리턴 값을 참조 할 수 있음. 리턴 값 자체를 바꿀 수는 없다. 그러나 참조 값이면 변경 가능. 리턴 참조가 필요없다면 굳이 매개변수를 선언할 필요는 없다.

• @AfterThrowing 예외가 발생하면 실행되는 어드바이스. 예외 타입과 파라미터 명이 일치해야 실행된다. 타입은 상위타입과 일치하면 된다

• @After 정상종료 or 예외가 처리되든 실행됨. finally 같은 존재

파라미터 선언과 바인딩

JoinPoint, ProceedingJoinPoint를 기본적으로 사용 ProceedingJoinPoint는 JoinPoint의 구현체로, 추가적인 기능을 더 담고 있다. 타겟 메서드 실행, 파라미터 값, 리턴값 변경 등 다양한 조작이 가능하다.

5.2 AspectJ와 @Configurable

AspectJ는 스프링 AOP와 달리 프록시를 사용하지 않고, 클래스의 바이트코드를 조작한다. 이렇게 복잡한 작업을 사용하는 이유는 프록시방식으로는 어드바이스를 적용 할 수 없는 조인포인트와 포인트컷 지시자를 지원하기 위해서다. 여기에서 AspectJ 같은 경우, AspectJ의 조인포인트는 필드의 읽기,쓰기 스태틱초기화, 인스턴스생성, 인스턴스초기화 등 스프링에서 제공하는 것보다 훨씬훨씬 많은 것을 지원한다. 그러나 대부분 99.9%는 스프링의 프록시 방식의 AOP로도 충분할 것이다. (메서드 기준의 포인트컷)

빈이 아닌 오브젝트에 DI 적용하기

DI를 적용하려면 기본적으로 스프링컨테이너에 Bean으로 등록이 되어야한다. User와 같은 오브젝트는 필요시에 매번 생성되어야하는데.. 이때 비즈니스 로직도 담겨있다면,...? 이런 설계를 DDD 관점에서 해석을 해야한다. 이런 오브젝트도 DI받을 수 있게하는 방법.. AOP가 그렇게 가능하도록 방식을 유도를 할 수 있는데, 스프링 AOP는 조인포인트에 오브젝트 생성까지 관여를 할 수는 없다... 그러나 AspectJ AOP는 가능하다... 이런 경우 AspectJ AOP가 필요한 것이다.

스프링에서 제공하는 AspectJ -> DependencyInjectionAspect (파일확장자 .aj)

DI애스펙트

@Configurable 붙은 클래스를 서칭해서 애스펙트를 적용한다. DI 설정방법은 3가지가 있다.

1. <bean>설정

   User을 빈으로 등록한 이유는 DI 받기위해서가 아니다.

   property에서 setter 주입을 받는 2개의 객체를 빈으로 DI 받기 위함.

   DI 애스펙트에서도 빈의 정보를 읽을 수 있다는 점도 있다.

   <bean class="A.B.C...User" abstract="true">
     <property name="userPolicyDao" ref="userPolicyDao"/>
     <property name="emailService" ref="emailService"/>
   </bean>

2. 자동와이어링

   빈설정은 필요 없음. 수정자 메서드에 대해 DI를 시도한다는 점이다.

      @Configurable(autowire=Autowire.BY_NAME)
      public class User{}

3. 애노테이션 의존관계 설정

이렇게 설정했으면... 이제 DI애스펙트 적용을 해야한다. -> 로드타임 위버와 자바 에이전트 AspectJ -> 클래스 로딩 시점 -> 바이트코드 조작 -> 로드타임위버 적용 필요 JVM의 javaagent 옵션 적용 -> JVM레벨 적용 필요 라이브러리 : aspectjweaver.jar -> 자바 에이전트로 지정, META-INF 밑에 aop.xml 설정 -> AspectJ 로드타임 위버도 있으나, 스프링이 직접 제공하는 로드타임위버 방식사용(spring-instrument-버전정보) 클래스패스 설정이 아닌 JVM 옵션 지정 필요(-javaagent:lib/org.springframework.instrument-버전.jar <context:load-time-weaver/> 설정 필요

META-INF 파일 밑에 aop.xml이 없다면, <context:load-time-weaver aspect-weaving="on"/> 설정 필요

이제 DI 애스펙트 등록 차례 <context:spring-configured/> 설정이 필요하다

5.3 로드타임 위버(LTW)

LTW 기능

1. @Configurable 지원 <context:spring-configured/>로 등록한 DI 애스펙트 동작 + AspectJ 로드타임 위버 기능 대체가능

2. AspectJ AOP 기능 지원 <tx:annotation-driven mode="aspectJ"/> -> 트랜잭션 AOP의 모드를 AspectJ로 설정할 때 역시 로드타임위버가 필요 (Spring AOP는 런타임위빙이다.)

3. JPA 사용시 JPA는 구현 제품에 따라서 대부분 로드타임 위버를 사용한 바이트코드 조작이 필요 POJO로 만든 도메인오브젝트에 지연로딩, 변경항목감시, 그룹조회, 조인을 이용한 로딩 및 최적화 기능 적용 -> 바이트코드 조작필요 -> JPA는 각 구현 제품마다 전용LTW를 제공

단점 1. AspectJ와 JPA의 LTW를 모두 적용해야 한다면... 문제 JVM의 자바에이전트 옵션 한번에 한가지만 적용 가능

1. JVM을 통해 로딩되는 모든 클래스를 전수 조사, 클래스 바이트 코드 조작대상으로 삼음 -> 부하를 일으키기 떄문에, 서버에 적용하기 부담

Spring이 제공하는 LTW는 두가지 문제 해결

1. JPA -> LocalContainerEntityManagerFactoryBean 이용 -> <context:load-time-weaver/> 추가 만으로 스프링의 LTW가 자동으로 JPA LTW로 사용됨 동시에 AspectJ LTW로도 동작함

2. 스프링 LTW -> 자바에이전트에 종속적이지 않음. LTW 태그 설정은 현재 애플리케이션 환경정보를 분석해서 적합한 LTW를 등록 함

WAS LTW 제공

• WAS 전용 LTW 제공 -> WebLogic, OC4J, GlassFish, JBossAS

• 그외 JVM 에이전트 -> 스프링활용

• 클래스로더 -> 스프링이 톰캣에는 전용 클래스로더 제공 (TomcatInstrumentableClassLoader) -> Context하위 <Loader loaderClass=클래스>에 설정

5.4 스프링 3.1의 AOP LTW

3.1부터 전용 애노테이션 추가

• @EnableAspectJAutoProxy

  @Aspect로 애스펙트를 정의할 수 있게 해주는 @AspectJ AOP 컨테이너 인프라빈을 등록해준다.

  <aop:apsectj-autoproxy>의 자바 버전

  ```java

  @Aspect

  public class MyAspect{}

@Configuration // -> 컨텍스트 역할 @EnableAspectAutoProxy // -> @Aspect AOP 컨테이너역할 담당 public class AppConfig{

@Bean // @Component로 하고 스캐닝을 통해 다른 곳에서 DI 가능
MyAspect myAspect(){
  return new MyAspect();  // Aspect 반환
}

}

- `@EnableLoadTimeWeaving`  
  XML의 `<context:load-time-weaver/>` 처럼 환경에 맞는 LTW 등록해주는 애노테이션  
  ```java
  @Configuration
  @EnableLoadTimeWeaving
  public class AppConfig{}