자바 AOP의 모든 것(Spring AOP & AspectJ)

이 글은 사전지식이 없다면 읽기 어려울 수 있다. 바이트코드와 리플렉션을 모른다면 아래의 글을 꼭 읽어보도록하자.

2021.08.17 - [기본 지식/Java 기본지식] - 바이트코드 조작(리플렉션, 다이나믹 프록시, 애노테이션 프로세서)

바이트코드 조작(리플렉션, 다이나믹 프록시, 애노테이션 프로세서)

 

스프링의 빈 포스트 프로세서

📌Spring boot 가 stereotype annotation 을 붙인 클래스들을 어떻게 찾고 bean 으로 등록하는지 그 과정을 최대한 상세하게 설명해주세요.

stereotype 어노테이션을 눌러보면, 안에 @Componet가 붙어있습니다. 즉 컴포넌트 스캔의 대상이 됩니다.

📑@Configuration 안에는 @ComponentScan이 붙어있습니다.
기본 값은 클래스의 패키지를 기점으로, 하위 패키지에 있는 모든 @Component들을 스캔합니다.

➡  물론 @ComponentScan 옵션으로 basePackages 변경하거나, includeFilters, excludeFilters로 필터링 변경 가능.
➡ 참고로 앵간한거 다 지원합니다. 정규표현식 , 특정어노테이션, 특정 클래스타입.. 다 필터링 가능합니다.
➡ 빈 이름은 클래스이름 그대로 사용하되, 첫글자를 소문자로 바꿉니다. (물론 @Componet(..name..) 으로 변경가능)

 

📑리플랙션을 사용하고자 해도, 해당 빈의 전체 클래스 경로가 필요합니다. 이는 런타임에는 알 수 없습니다.
➡ @ComponentScan의 위치를 기점으로 모든 하위 패키지를 탐색하여 @Component를 찾습니다.
➡ 물론 무지성으로 프로젝트 전체 패키지를 스캔할 수 있으나, 이는 빌드 타임이 매우 느려집니다.

📑 재밌는 점은, 스프링은 어노테이션이 아니라 XML이나 커스텀한 방법으로도 빈 등록이 가능합니다.
스프링 컨테이너는 BeanDefinition 이라는 객체만 사용합니다. Reader는 추상화되어있으며 갈아끼울 수 있습니다.
실제로 스프링 컨테이너(ApplicationContext)는 구현체에 따라 다른 BeanDefinitionReader를 가지고 있습니다.

참고로 Bean을 관리하고 조회하는건 BeanFactory 인터페이스가 담당합니다.

ApplicationContext는 총 5개의 인터페이스를 상속받습니다.

// 생략한게 아니라, 전체 코드입니다. 의외로 심플합니다.
public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory,
                                    HierarchicalBeanFactory, MessageSource, 
                                    ApplicationEventPublisher, ResourcePatternResolver {
    @Nullable
    String getId();

    String getApplicationName();

    String getDisplayName();

    long getStartupDate();

    @Nullable
    ApplicationContext getParent();

    AutowireCapableBeanFactory getAutowireCapableBeanFactory() throws IllegalStateException;
}

📑 스프링에선 실제 빈 대신, 프록시가 컨테이너에 삽입되기도 합니다. 
프록시를 사용하면 빈 후처리기 (BeanPostProcessor)에서 빈을 런타임에 바꿔치기한 후 컨테이너에 등록합니다.
이 때 설정을 몇 개를 추가하든 단 1개의 프록시만 생성됩니다. CGLIB를 사용하는 다이나믹 프록시의 장점! 

물론 프록시가 필요없다면 원본객체가 스프링 빈으로 등록됩니다.

📑 아, 물론 프로토타입 빈은 컨테이너에 없답니다. 이는 빈후처리기 이후 의존성 주입이 끝나면 버리는거에요
(클래스는 가지고 있음. 인스턴스를 컨테이너에 관리하지않아서, 다시 요청하면 새로 만들어줌) 

📑 단, 빈에서 생성자 주입을 사용안하면 객체가 먼저 생성된 후, 나중에 의존성이 주입됩니다.
그래서 초기화용 / 종료용 콜백 메서드를 작성해놨다가, 해당 시점에 실행하도록 만들 수 있습니다.

@Configuration
static class LifeCycleConfig {
	// 해당 객체에 메서드 이름을 넘기면 됩니다. 물론 없으면 스프링에러.
    @Bean(initMethod = "init", destroyMethod = "close")
    public NetworkClient networkClient() {
        NetworkClient networkClient = new NetworkClient();
        networkClient.setUrl("http://hello-spring.dev");
        return networkClient;
    }
}

이게 번거롭다면, 아래와 같이 클래스에 직접 @PostConstruct, @PreDestory 를 붙여도 똑같이 동작합니다.

public class NetworkClient {
    private String url;
 
    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }
    
    ... 생략 ...
 
    @PostConstruct
    public void init() {
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }
 
    @PreDestroy
    public void close() {
        System.out.println("NetworkClient.close");
        disConnect();
    }
}

이 어노테이션이 없을 때에는 인터페이스(InitalizingBean, DispoableBean)을 구현하거나 xml로 적었는데,
해당 어노테이션이 생기고 나서는 거의 안쓰는 기능이에요. 참고로 처리되는 순서는 아래와 같습니다.

 

---

# 스프링의 Proxy

스프링AOP는 프록시 패턴을 기반으로 설계되었다. 하지만 실제로는 디자인패턴에서 말하는 Proxy패턴과는 조금 다른데, 디자인패턴에서 Proxy패턴은 타겟의 대한 기능을 확장하지는 않고, Client가 Target에 접근하는 방식을 변경하는 코드 패턴을 의미하기 때문이다.

스프링에서 말하는 프록시는 리플렉션과 바이트코드 조작을 이용해 실제 타겟의 기능을 대신 수행하면서, 기능을 확장하거나 추가할 수도 있는(OCP원칙) 다이나믹 프록시 객체를 의미한다.

 

좀 더 쉽게말하자면, 스프링 AOP는 [런타임에 프록시 인스턴스가 동적으로 변경되는] 다이나믹 프록시 기법으로 구현되어져있다.

---

# JDK Dynamic Proxy

자바에서 제공하는 API (java.lang.reflect.Proxy)를 사용하며 인터페이스 기반으로 Proxy를 생성한다. 사용방법에는 여러가지가 있지만 개발자는 InvocationHandler 객체의 invoke()메서드를 오버라이딩하여 실제 객체의 정보를 받아오고 조작하면 된다.

이렇게 프록시 객체를 하나하나 직접 만드는게 아니라, 런타임 시점에 [클래스 정보 Object.class]를 이용하여 어노테이션, 메서드에 따라 동적으로 다른 메서드 동작을 실행하도록 프록시를 만들 수 있다. 

// BookService 인터페이스에 프록시 객체 인스턴스를 런타임에 동적으로 등록하는 방법.
BookService bookService = (BookService) Proxy.newProxyInstance(
            BookService.class.getClassLoader() // 프록시를 만들 ClassLoader
            ,new Class[]{BookService.class} // 프록시를 만들 인터페이스
            ,new InvocationHandler() { //invoke handler, 프록시의 내용. 직접 작성한 구현체
                BookService bookService = new DefaultBookService();
 
                @Override
                public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                    // 아무런 동작도 하지않고, 단순히 실제 객체에게 위임하는 프록시 코드.
                    // Object invoke = method.invoke(...)등으로 리플렉션 조작가능.
                    // method.invoke(메서드를 호출할 객체 , 메서드에 전달할 파라메타)
                    // 여기에 코드를 작성하면 객체의 모든 메서드가 동일한 영향을 받는다.
                    return method.invoke(bookService, args);
                }
            });

예를 들어 BookService 인터페이스의 특정 메서드( ex rent() )에 추가적인 동작을 하는 프록시 객체를 만들고 싶다면, 아래와 같이 작성하면 된다. 필요하다면 다른 객체에서 메서드를 실행하도록 바꿀수 있다. (invoke의 첫번째 인자)

if (method.getName().equals("rent")) {
    System.out.println("aaaa 실행 전 추가 동작");
    // method.invoke(메서드를 호출할 객체 , 메서드에 전달할 파라메타)
    Object invoke = method.invoke(bookService, args);// 메서드를 실행하여 결과를 반환받는다.
    System.out.println("bbbb 실행 후 추가 동작");
    return invoke; // 이제 이 메서드는 여기서 return한 반환값을 가지게 된다.
}

 

다만 사용해보면 알겠지만, 특정 메소드만 사용하고 싶더라도 [해당 객체 정보]를 리플렉션(object.class)을 통해 통째로 가져와서 위의 예제 처럼 조건문을 이용해 프록시 객체를 만들어야 한다. 코드가 상당히 복잡해진다.

 

---

# CGlib proxy

CGlib는 바이트코드를 조작하여 프록시 객체를 생성해주는 코드 생성(Code gen)라이브러리이다.

• JDK 프록시는 인터페이스에 적혀있는 모든 메서드에 프록시를 적용시킨다. 그리고 Class<T>정보로 조건문을 만들어 특정 메서드만 추가동작을 하도록 만들 수 있다.
• CGlib는 MethodMatcher 객체를 사용하여 특정 메서드만 프록시화 하고, 나머지는 프록시를 거치지 않고 실제 객체 메서드를 호출하도록 만들 수 있다.
• 이게 가능한 이유는 CGlib는 인터페이스가 아닌 타겟 객체를 직접 상속받아 만들기 때문이다.

MethodInterceptor handler = new MethodInterceptor() {
    private final MethodMatcher methodMatcher; // 특정 메서드를 찾는 객체
    BookService bookService = new BookService();
	
    public MethodInterceptor(MemthodMatch m){
    	this.methodMatcher = m;
    }
    
    @Override
    public Object intercept(Object o, Method method, Object[] objects, MethodProxy
            methodProxy) throws Throwable {    
        if (methodMatcher.matches(method)) {
            // CGlib는 상속된 프록시 객체를 사용하기에 특정메서드만 프록시로 바꿀 수 있음
            // JDK 다이나믹 프록시와 다르게 필요없는 메서드는 프록시를 안거치게 할수있음.
            return methodName.toUpperCase();
        }
        return method.invoke(bookService, objects);
    }
};

// CGlib로 조작한 프록시 객체를 삽입
BookService bookService = (BookService) Enhancer.create(BookService.class, handler);

 

---

# 그래서 이걸 스프링 AOP에 어떻게 적용하는데요?

• [JDK 프록시의 InvocationHandler], [CGlib의 MethodInterceptor]는 스프링 AOP에서 JoinPoint 개념이다.
• [JDK 프록시의 조건문], [CGlib의 MethodMatcher]는 스프링 AOP의 PointCut 개념이다.
• [JDK invoke 메서드 내용], [CGlib 의 Intercept 메서드 내용]은 스프링 AOP의 Advice 개념이다.

spring AOP, 아래에서 차근차근 설명할 예정이다.

다만 스프링 AOP를 활용한다고 해서 프록시를 처음부터 구현하지는 않는다. @AspectJ과 어떻게 Advice를 지정할 건지에 대한 설정(@Before, @Around, @AfterThrowing...) 그리고 특정 조건을 필터링할 Expression을 기반으로 PointCut 을설정한다.

 

---

 

# 스프링 AOP에 대해 감을 잡아보자

@ AOP 란?

관점 지향 프로그래밍(Aspect Oriented Progamming) 기법은 객체지향을 보완하는 수단으로, 흩어진 관점(Aspect)를 모듈화 하여 비즈니스 로직을 헤치지 않고 재사용하는 프로그래밍 기법이다.

AOP의 예제) [비즈니스 로직의 관심사]와 [설정, 로그부분의 관심사]를 모듈로 분리하고 재사용 할 수 없을까?

스프링에서는 어노테이션을 통해 AOP를 쉽게 구현할 수 있도록 만들어준다.

@Component
@Aspect // 모든 메서드의 성능을 시간으로 측정하는 Cross-cutting corncern 객체
public class TimeTraceAop { 
    @Around("execution(* hello.hellospring..*(..))")
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        System.out.println("START: " + joinPoint.toString());
        try {
            return joinPoint.proceed();
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("END: " + joinPoint.toString() + timeMs + "ms");
        }
    }
}

 

---

@ AOP에서 사용하는 용어

Aspect : 공통 관심사(Cross-cutting corncern)을 모듈화 한 것

Target : Aspect(공통관심사)를 적용할 핵심로직을 가진 객체
Weaving - Aspect 를 대상 객체(Target)에 연결시켜 AOP 객체로 만드는 바이트 코드 및 객체 조작과정

Advice : Aspect(공통관심사)의 동작을 적은 것. Aspect의 구현체 (객체의 메서드조작)

• Join Point : Advice가 적용되는 시점. (메서드 실행, 생성자 호출, 필드 값 변경같은 특수한 실행 시점)
   return joinPoint.proceed(); 
• Pointcut : [Join Point]의 정규식 => 실행 스펙, Pointcut이 일치하는 객체들에게 Aspect 적용(조건문)
   @Pointcut("execution(* hello(..))") 
  

예제) 시간측정로직이라는 공통관심사항을 Aspect로 모듈화 하고 싶다.

@Aspect 어노테이션을 통해 다이나믹 프록시객체를 만들어 공통관심사항을 TimeTraceAOP로 분리시켰다.

 

---

@ AOP를 구현하는 방법(AspectJ 와 스프링AOP)

AOP를 구현하는 방법에는 여러가지가 있고, 그만큼 다양한 AOP 라이브러리와 도구들이 존재한다. 대부분 바이트코드 Weaving을 사용하여 구현하며 대부분 AspectJ와 Spring AOP 이 2가지 도구를 활용하여 AOP를 구현한다.

 

• Spring AOP 는 스프링에서 사용할 수 있는 간단한 AOP 기능만을 제공한다.
  - CGlib등의 바이트코드 조작을 이용한 다이나믹 프록시를 사용해서 AOP 기능을 제공한다.
  - 런타임 시점에 동적으로 변할 수 있는 프록시 객체를 이용하기에 앱 성능에 영향을 끼칠 수 있다.
  

  

  
  
  
• AspectJ 는 자바에서 완벽한 AOP 솔루션 제공을 목표로하는 기술이다.
  - [ .aj 파일]을 이용한 assertj 컴파일러를 추가로 사용하여 컴파일 시점이나 JVM 클래스 로드시점에 조작한다.
  - 런타임 시점에는 영향끼치지 않는다. 즉 컴파일이 완료된 이후에는 앱 성능에 영향이 없다.
  - 밑에서 몸으로 느끼겠지만, Spring AOP에 비해 사용방법이 다양하고 내부 구조가 굉장히 복잡하다.
  참고로 spring aop를 개발할 때, AspectJ의 개발자가 CTO로 참여했다고 한다.
  

  

  AspectJ는 총 3가지 유형의 바이트코드 weaving을 사용한다.

---

 

# AspectJ 와 SpringAOP 비교하기

@1. 기능과 목표가 다르다.

• Spring AOP는 프로그래머가 직면하는 일반적인 문제 해결을 위해 Spring IoC에서 제공하는 간편한 AOP 기능이다. 어디에나 쓸 수 있는 완벽한 AOP 솔루션이 아니라, [Spring 컨테이너가 관리하는 Bean]에만 사용하려고 만들었고, 실제로 여기에만 AOP를 적용 할 수 있다.
  
  
• AspectJ는 [자바코드에서 동작하는 모든 객체]에 대해 완벽한 AOP 솔루션 제공을 목표로 하는 기술이다. 성능이 뛰어나고 기능이 매우 강력하지만 그만큼 Spring AOP에 비해 사용방법이나 내부 구조가 훨씬 더 복잡하다. 

 

---

@2. Weaving 방법이 다르다.

Weaving은 공통관심사항(Aspect)의 동작코드(Advice)를 대상 객체(Target)에 연결시켜 관점지향을 구현한 객체로 만드는 과정이다. 좀 더 쉽게말하면 AOP를 구현하기 위한 바이트코드 조작 방법을 의미한다고 생각하면 된다.

* 소스코드로 위빙을 구현(Source-code Weaving)하는게 가장 좋긴 하겠지만, 현재까지 자바언어가 제공하는 기능으로는 완벽한 AOP를 구현하기 어렵다. 억지로 비슷하게 만들어봐야 코드가 복잡해져 유지보수가 어렵고 오버헤드가 심해지기에 아직까지는 바이트코드를 조작하여 제공하는 AOP 도구만 존재한다.

 

* 참고로 각 위빙 방법의 앞글자를 따서 RTW CTW, BW(또는 PCW), LTW 라고 줄여서 많이 사용한다. 적기 힘드니까.

 

Spring AOP는 위에서 설명한 런타임 위빙(다이나믹 프록시)를 사용한다.

• 자바의 리플렉션 API와 CGlib등의 도구로 런타임시 동적인 프록시 객체를 만든다.
• 동적인 프록시 객체란, 클래스의 정보에 따라 런타임시에 다르게 구현되도록 만드는 객체를 의미한다.
• 복잡한 설정없이 Spring 빈 등록을 하게되면 자동으로 등록되어 사용하기 매우 편하다.
• 근데 런타임에 바이트코드를 조작하는 만큼, 오버헤드가 심하고 성능에 영향을 크게 미칠 수 있다.
  벤치마킹상 AspectJ가 Spring AOP보다 최소 8배, 최대 35배정도 빠르다. 

참고로 옛 스프링은 AOP 타깃이 인터페이스를 구현했다면 JDK를, 아니라면 Class 방식을 사용했었다. (권장은 안하지만 지금도 설정에서 변경가능)

 

AspectJ는 3가지 유형의 Weaving을 제공한다.

• 1. Compile-Time 위빙 : AspectJ 전용 컴파일러를 이용하여 Aspect 부분과 Target 코드 부분을 입력으로 받고 하나로 엮인 바이트코드(.class)를 생성한다. 컴파일이 완료된 이후에는 앱의 성능에 전혀 영향을 끼치지 않는다.
  
  
• 2. Post-Complie 위빙 : 외부 라이브러리를 Weaving 할 때 사용한다. [Compile-Time 위빙]과 거의 동일한 동작을 한다.  보통 클래스파일을 JAR와 엮기 위해서 사용해서 [Binary 위빙]이라고 부르는게 일반적이다. 
  
  
• 3. Load-time 위빙 :  전용 컴파일러를 사용하지않고, 조작되지 않은 바이트코드(.class)를 가 JVM에 로드 될 때 ClassLoader를 이용하여 바이트코드를 조작하는 위빙 방식이다. 객체를 로드할 때 위빙이 일어나는 거라 앱 성능의 하락을 발생시킬 수 있다.

참고로 CTW, LTW는 동작은 같은 인터페이스에서 설정값을 추가하는 것으로 쉽게 변경할 수 있다.

// 기본값, 컴파일 타임 위빙
@EnableTransactionManagement(mode = AdviceMode.ASPECTJ, order = 0)

// 로드 타임 위빙
@EnableTransactionManagement(mode = AdviceMode.ASPECTJ, order = 0)
@EnableLoadTimeWeaving

 

 

CTW(Complie-Time Weaving) vs LTW(Load-time Weaving)

* LTW (Load-Time Weaving)

• JVM이 바이트코드(.class) 로드할 때 AspectJ이 가로채서 위빙된 객체를 넘겨주는 방식.
• CTW와 다르게 실행되기 전까지는 바이트코드를 변경하지 않기때문에 컴파일 시간이 짧아진다는 장점이 있지만 클래스가 메모리에 올라가는 과정에서 위빙이 일어나기 때문에 [Complie-Time 위빙]과 다르게 런타임 성능에 영향을 끼칠 수 있다.
  
  
• 또한 스프링에서 사용할 시 App..Context에 객체가 로드될 때, [aspectj 위빙]작업뿐만 아니라 [Spring-instrument]도 각각 객체에 대한 추가적인 처리를 해줘야한다. Spring-instrument는 aspectj에 class loader를 위임하는 역할을 맡는다. => 성능 하락, 물론 LTW 설정을 통해 성능 하락을 막을 수 있다.
• 이렇게 사용하기 위해서는 JVM argument에 다음과 같은 옵션을 추가해야한다.
  

  -javaagent:/fullpath/aspectjweaver-1.8.1.jar
  -javaagent:/fullpath/spring-instrument-4.0.6.RELEASE.jar​

그럼에도 불구하고 LTW를 사용하는 이유는 [런타임 위빙]처럼 동적인 위빙을 구현할 수 있기 때문.

 

* CTW (Compile-Time Weaving)

• 아예 컴파일하는 시점에 AspectJ 컴파일러를 이용하여 하나의 바이트코드(.class)로 만들어버리는 방식.
• 컴파일이 완료된 바이트코드는 어떠한 위빙도 일어나지 않기에 앱 성능에 전혀 영향이 없다.
• 다만 lombok과 같이 컴파일 과정에서 조작을 하는 플러그인과 충돌하여 컴파일 오류가 발생할 가능성이 매우 높다. (사실상 같이 사용하지 못한다.)

컴파일타임, classLoader 타임, 런타임

---

@3. 결론

Spring AOP가 성능과 기능은 매우 부족하지만, Spring Bean에 자동으로 적용되고 설정하기 매우 편리하다. 또한 AspectJ와 다르게 컴파일 시점에 건드리는게 없어서 각종 라이브러리(Lombok)과 호환성이 뛰어나다.

Spring AOP가 사용방법도 간단하고, 플러그인 호환성도 좋다. 하지만 Bean에만 적용가능하고 성능이 별로..

하지만 Spring AOP는 컨테이너 안의 Bean만 조작할 수 있고, JoinPoint를 메서드호출시점밖에 적용 못한다는 단점이 있다. 반면에 AspectJ는 런타임이 아닌 컴파일 시점에 동작하는 도구라서 다음과 같이 다양한 시점을 지정할 수 있다.

 

---

 

# 머리아프다.. 스프링 AOP 사용방법이나 알아보자

@ 한눈에 보는 스프링AOP

스프링3.2 이후 CGlib가 Spring-Core에 포함되었고, 스프링부트에서는 전부 CGLib를 사용한다.

 

프록시 라이브러리의 사용방법

 

네? 스프링부트는 전부 CGLib로 프록시를 구현한다고요?

참고로 스프링 3.2 이전에는 AOP 타깃이 인터페이스를 구현했다면 JDK를, 아니라면 Class 방식을 사용하는게 기본값이었다. (권장은 안하지만 지금도 설정에서 변경가능)

https://gmoon92.github.io/spring/aop/2019/04/20/jdk-dynamic-proxy-and-cglib.html

 

@ 스프링 AOP 퀵 스타터

1. 의존성 추가

dependencies {
	implementation('org.springframework.boot:spring-boot-starter-aop')
}

 

 

2. Aspect 클래스 만들기

• 스프링AOP는 Bean(@Component, @Bean)으로 등록된 객체만 Aspect로 만들 수 있다.

@Component
@Aspect
public class PerfAspect {
	// 상속도 하지 않았는데 logPerf 메서드를 사용 할 수 있는 이유 => 런타임 동적 프록시
    @Around("@annotation(PerfLogging)")
	public Object logPerf(ProceedingJoinPoint joinPoint) throws Throwable { ... }
}

 

 

3. Aspect의 동작 코드 (Advice) 작성하기

• @Around를 메서드에 붙여 통해 Target의 앞, 뒤에 공통관심부분의 코드 (Advice)를 작성할 수 있다.
• 메서드에서 Target 메서드가 실행될 지점에 joinPoint.proceed()를 호출해주면 된다.
  

  

  참고로 @Around 말고 다양한 Advice 태그들을 제공해준다. 필요하면 사용하도록하자.

   

@Around만 사용해도 모든게 가능하지만, 필요에 따라 범위를 제한해둘 수 있다.

 

// @Around("execution(* hello.hellospring..*(..))") 이렇게 쓰면 정규식으로 클래스 필터가능

@Around("@annotation(PerfLogging)") // @perfLoggin 어노테이션에 AOP 적용
public Object logPerf(ProceedingJoinPoint joinPoint) throws Throwable {
	//Advice가 적용될 대상 (메서드 그 자체)
	long start = System.currentTimeMillis();
	Object retVal = joinPoint.proceed(); // Target 메서드가 실행될 시점
	System.out.println(System.currentTimeMillis() - start);
	return retVal;
}

 

• 만약 메서드 실행이전, 이후 동작을 분리하고 싶다면 위에서 언급한 @Before @After 등을 같이 사용하면 된다.

@Before("bean(myEventService)")
public void Hello(JoinPoint jp) {
    System.out.println("Hello");
}

 

 

3-1 Aspect 클래스 구현 예제

예를 들어 @LoginAuth 태그가 붙은 빈에 Session 검증을 해주는 Aspect 모듈을 만들고 싶다면, 아래와 같이 사용하면 된다.

// 소스의 패키지 경로가 다를 경우 클래스명 대신에 전체 패키지명을 입력해주면 됨.
@Around("@annotation(project.board.annotation.LoginAuth)")
public String loginAuth(ProceedingJoinPoint pjp) throws Throwable {
	HttpSession session = null;
	for(Object o : pjp.getArgs()) {//pjp.getArgs()는 Target에 넘겨진 매개변수들.
		if(o instanceof HttpSession) {
			session = (HttpSession) o;
		}
	}
	
	if(session.getAttribute("memberId")==null) {
		return "member/login";
	}
	return (String) pjp.proceed();
}

 

 

4. 포인트컷 @PointCut("~") 정규표현식 사용

• 포인트컷이란 Aspect를 적용시킬 Target 객체를 지정하는 것을 의미한다.
• 위에도 말했지만 포인트컷은 @Around("~여기~")에 작성해도 된다.
• 정규표현식을 쓴다고 한들, 스프링 AOP는 메서드에만 JoinPoint를 붙일 수 있다. (필드 같은거 안됨)

@Pointcut("excution(...정규표현식...)")

execution([접근제한자패턴] 리턴값_패턴 [타입패턴.] 메소드이름_패턴 (파라미터_타입_패턴))

// [...] 부분은 생략해서 적어도 상관없다.
execution(리턴값_패턴 메소드이름_패턴 (파라미터_타입_패턴))

@Pointcut("execution(* hello(..))") // 이름이 hello인 모든 메서드
@Around("@annotation(project.board.annotation.LoginAuth)") // @LoginAuth가 붙은 메서드
@Around("execution(* hello.hellospring..*(..))") // hello.hellospring. 패키지 안 모든 메서드

 

포인트컷은 아래와 같이 사용할 수도 있다. all() 메서드에 포인트컷을 적용시키고 돌려쓰는 방식

public class Hi{
	// 모든 타입[반환타입, 메소드이름, 매개변수]중 이름이 hello인 대상
	@Pointcut("execution(* hello(..))") 
	private void all(){}

	@Around("all()")
	public Object printParametersAndReturnVal(ProceedingJoinPoint pjp) throws Throwable{
		...
		Object ret = pjp.proceed();
		...
		return ret;
	}
 }

 

# 레퍼런스

https://gmoon92.github.io/spring/aop/2019/04/20/jdk-dynamic-proxy-and-cglib.html

https://logical-code.tistory.com/118

https://kils-log-of-develop.tistory.com/638

https://www.inflearn.com/course/the-java-code-manipulation

https://www.baeldung.com/aspectj