[스프링 핵심 원리 - 고급편] #06. 스프링이 지원하는 프록시

[Pracrobo]

프록시 팩토리 - 소개

앞서 마지막 설명했던 동적프록시를 사용할때 문제점을 다시 확인해보면

문제점

• 인터페이스가 있는 경우에는 JDK 동적 프록시를 적용하고 그렇지 않은 경우에는 CGLIB를 적용하려면 어떻게 해야할까?
• 두 기술을 함께 사용할때 부가 기능을 제공하기 위해 JDK 동적 프록시가 제공하는 InvocationHandler 와 CGLIB가 제공하는 MethodInterceptor 를 각각 중복으로 만들어서 관리해야 할까?
• 특정 조건에 맞을때 프록시 로직을 적용하는 기능도 공통으로 제공되었으면?

Q: 인터페이스가 있는 경우에는 JDK 동적 프록시를 적용하고 그렇지 않은 경우에는 CGLIB를 적용하려면 어떻게 해야할까?

스프링은 유사한 구체적인 기술들이 있을때 그것들을 통합해서 일관성 잇게 접근할 수 있고 더욱 편리하게 사용할 수 있는 추상화된 기술을 제공한다.

스프링은 동적 프록시를 통합해서 편리하게 만들어주는 프록시 팩토리(ProxyFactory) 라는 기능을 제공한다.

이전에는 상황에 따라서 JDK 동적 프록시를 사용하거나 CGLIB 를 사용해야 했다면, 이제는 이 프록시 팩토리 하나로 편리하게 동적 프록시를 생성할 수 있다.

프록시 팩토리는 인터페이스가 있으면 JDK 동적 프록시를 사용하고 구체클래스만 있다면 CGLIB 를 사용한다. 그리고 이 설정을 변경할 수도 있다.

프록시 팩토리

Q: 두 기술을 함께 사용할 때 부가 기능을 적용하기 위해 JDK 동적 프록시가 제공하는 InvocationHandler와 CGLIB 가 제공하는 MethodInterceptor를 각각 중복으로 따로 만들어야 할까?

스프링은 이 문제를 해결하기 위해 부가기능을 적용할 때 Advice 라는 새로운 개념을 도입했다. 개발자는 InvocationHandler 나 MethodInterceptor를 신경쓰지 않고 Advice 만 만들면 된다.

결과적으로 InvocationHandler 나 MethodInterceptor 는 Advice 를 호출하게 된다.

프록시 팩토릴르 사용하면 Advice 를 호출하는 전용 InvocationHandler , MethodInterceptor 를 내부에서 사용한다.

Advice 도입

Advice도입 전체흐름

Q : 특정 조건에 맞을때 프록시 로직을 적용하는 기능도 공통으로 제공되었으면?

앞서 특정 메서드 이름의 조건에 맞을때만 프록시 부가 기능이 적용되는 코드를 직접 만들었다. 스프링은 Pointcut 이라는 개념을 도입해서 이 문제를 일관성잇게 해결한다.

프록시 팩토리 - 예제 코드 1

Advice 만들기

Advice 는 프록시에 적용하는 부가 기능 로직이다. 이것은 JDK 동적 프록시가 제공하는 InvocationHandler와 CGLIB가 제공하는 MethodInterceptor 의 개념과 유사한다. 둘을 개념적으로 추상화 하것 이다. 프록시 팩토리르르 사용하면 둘 대신에 Advice 를 사용하면 된다.

Advice 를 만드는 방법은 여러가지가 있지만 기본적인 방법은 다음 인터페이스를 구현하면 된다.

MethodInterceptor - 스프링이 제공하는 코드

package org.aopalliance.intercept;

public interface MethodInterceptor extends Interceptor {
	Object invoke(MethodInvocation invocation) throws Throwable;
}

• MethodInvocation invocation
  • 내부에는 다음 메서드를 호출하는 방법, 현재 프록시 객체 인스턴스, args , 메서드 정보 등이 포함되어 있다. 기존에 파라미터로 제공되는 부분들이 이 안으로 모두 들어갔다고 생각하면 된다.
• CGLIB 의 MethodInterceptor 와 이름이 같으므로 패키지 이름에 주의하자
  • 참고로 여기서 사용하는 org.aopalliance.intercept 패키지는 스프링 AOP 모듈(spring-top) 안에 들어있다.
• MethodInterceptor 는 Interceptor를 상속하고 Interceptor는 Advice 인터페이스를 상속한다.

이제 실제 Advice를 만들어보자.

TimeAdvice

package hello.proxy.common.advice;

import java.lang.reflect.Method;
import lombok.extern.slf4j.Slf4j;
import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;

@Slf4j
public class TimeAdvice implements MethodInterceptor {
    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {

        log.info("TimeProxy 실행");
        long startTime = System.currentTimeMillis();

       // Object result = method.invoke(target, args); //call
        Object result = invocation.proceed();
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("TimeProxy 종료 resultTime ={}", resultTime);
        return result;
    }
}

invocation.proceed() 에서 다 가져온다.

• TimeAdvice 는 앞서 설명한 MethodInterceptor 인터페이스를 구현한다. 패키지 이름에 주의하자.
• Object result = invocation.proceed()
  • invocation.proceed() 를 호출하면 target 클래스를 호출하고 그 결과를 받는다.
  • 그런데 기존에 봤던 코드들과 다르게 target 클래스의 정보가 보이지 않는다. target 클래스의 정보는 MethodInvocation invocation 안에 모두 포함되어 잇다.
  • 그 이유는 바로 다음에 확인할 수 있는데 프록시 팩토리로 프록시를 생성하는 단계에서 이미 target 정보를 파라미터로 전달받기 때문이다.

ProxyFactoryTest

package hello.proxy.proxyfactory;

import static org.assertj.core.api.Assertions.assertThat;

import hello.proxy.common.advice.TimeAdvice;
import hello.proxy.common.service.ServiceImpl;
import hello.proxy.common.service.ServiceInterface;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.aop.framework.ProxyFactory;
import org.springframework.aop.support.AopUtils;

@Slf4j
public class ProxyFactoryTest {

    @Test
    @DisplayName("인터페이스가 있으면 JDK 동적 프록시 사용")
    void interfaceProxy() {
        ServiceInterface target = new ServiceImpl();
        ProxyFactory proxyFactory = new ProxyFactory(target);

        proxyFactory.addAdvice(new TimeAdvice());
        ServiceInterface proxy = (ServiceInterface) proxyFactory.getProxy();
        log.info("targetClass={}", target.getClass());
        log.info("proxyClass={}", proxy.getClass());

        proxy.save();
        assertThat(AopUtils.isAopProxy(proxy)).isTrue(); //iisFalse() 하면 xx
        assertThat(AopUtils.isJdkDynamicProxy(proxy)).isTrue();
        assertThat(AopUtils.isCglibProxy(proxy)).isFalse();

    }
}

• new ProxyFactory(target) : 프록시 팩토리를 생성할때 , 생성자에 프록시의 호출대상을 함께 넘겨준다. 프록시 팩토리는 이 인스턴스 정보를 기반으로 프록시를 만들어낸다. 만약 이 인스턴스에 인터페이스가 있다면 JDK 동적 프록시를 기본으로 사용하고 인터페이스가 없고 구체클래스만 잇다면 CGLIB 를 통해서 동적 프록시를 생성한다. 여기서는 target 이 new ServiceImpl()의 인스턴스이기 때문에 ServiceInterface 인터페이스가 있다. 따라서 이 인터페이스를 기반으로 JDK 동적프록시를 생성한다.
• proxyFactory.addAdvice(new TimeAdvice()) : 프록시 팩토리를 통해서 만든 프록시가 사용할 부가 기능 로직을 설정한다. JDK 동적 프록시가 제공하는 InvocationHandler 와 CGLIB 가 제공하는 MethodInterceptor의 개념과 유사하다. 이렇게 프록시가 제공하는 부가 기능 로직을 어드바이스(Advice) 라 한다. 번역하면 조언을 해준다고 생각하면 된다.
• proxyFactory.getProxy() : 프록시 객체를 생성하고 그결과를 받는다.

실행결과

실행 결과를 보면 프록시가 정상 적용된 것을 확인할 수 있다. proxyClass=class com.sun.proxy.$Proxy13 코드를 통해 JDK 동적 프록시가 적용된 것도 확인할 수 있다.

프록시 팩토리를 통한 프록시 적용 확인

프록시 팩토리로 프록시가 잘 적용되었는지 확인하려면 다음 기능을 사용하면 된다.

• AopUtils.isAopProxy(proxy) : 프록시 팩토리를 통해서 프록시가 생성되면 JDK 동적 프록시나 CGLIB 모두 참이다.
• AopUtils.isJdkDynamicProxy(proxy) : 프록시 팩토리를 통해서 프록시가 생성되고 JDK 동적 프록시인 경우 참
• AopUtils.isCglibProxy(proxy) : 프록시 팩토리를 통해서 프록시가 생성되고 CGLIB 동적 프록시인 경우 참

물론 proxy.getClass() 처럼 인스턴스의 클래스 정보를 직접 출력해서 확인할 수 있다.

프록시 팩토리 - 예제코드2

OrderRepositoryConcreteProxy추가

    @Test
    @DisplayName("구체 클래스만 있으면 CGLIB 사용")
    void concreteProxy() {
        ConcreteService target = new ConcreteService();
        ProxyFactory proxyFactory = new ProxyFactory(target);
        proxyFactory.addAdvice(new TimeAdvice());

        ConcreteService proxy = (ConcreteService) proxyFactory.getProxy();
        log.info("targetClass={}", target.getClass());
        log.info("proxyClass={}", proxy.getClass());

        proxy.call();
        assertThat(AopUtils.isAopProxy(proxy)).isTrue(); //iisFalse() 하면 xx
        assertThat(AopUtils.isJdkDynamicProxy(proxy)).isTrue();
        assertThat(AopUtils.isCglibProxy(proxy)).isFalse();

    }

실행결과

실패

변경

        proxy.call();
        assertThat(AopUtils.isAopProxy(proxy)).isTrue(); //iisFalse() 하면 xx
        assertThat(AopUtils.isJdkDynamicProxy(proxy)).isFalse();
        assertThat(AopUtils.isCglibProxy(proxy)).isTrue();

3번째 - ProxyTargetClass 추가

    @Test
    @DisplayName("ProxyTargetClass 옵션을 사용하면 인터페이스가 있어도 CGLIB를 사용하고, 클래스 기반 프록시 사용")
    void proxyTargetClass() {
        ServiceInterface target = new ServiceImpl();
        ProxyFactory proxyFactory = new ProxyFactory(target);
        proxyFactory.setProxyTargetClass(true);
        proxyFactory.addAdvice(new TimeAdvice());
        
        ServiceInterface proxy = (ServiceInterface) proxyFactory.getProxy();
        log.info("targetClass={}", target.getClass());
        log.info("proxyClass={}", proxy.getClass());

        proxy.save();
        assertThat(AopUtils.isAopProxy(proxy)).isTrue(); //iisFalse() 하면 xx
        assertThat(AopUtils.isJdkDynamicProxy(proxy)).isTrue();
        assertThat(AopUtils.isCglibProxy(proxy)).isFalse();

    }

마지막으로 인터페이스가 있지만, CGLIB 를 사용해서 인터페이스가 아닌 클래스 기반으로 동적 프록시를 만드는 방법을 알아보자. 프록시 팩토리는 proxyTargetClass 라는 옵션을 제공하는데 이 옵션에 true 값을 넣으면 인터페이스가 있어도 강제로 CGLIB를 사용한다. 그리고 인터페이스가 아닌 클래스 기반의 프록시를 만들어준다.

실행결과

• ServiceImpl$$EnhanceBySpringCGLIB… 를 보면 CGLIB 기반의 프록시가 생성된 것을 확인할 수 있다. 인터페이스가 있지만 proxyTargetClass 옵션에 의해 CGLIB 가 사용된다.

프록시 팩토리의 기술 선택 방법

• 대상에 인터페이스가 있으면 : JDK 동적 프록시 , 인터페이스 기반 프록시
• 대상에 인터페이스가 없으면 : CGLIB , 구체 클래스 기반 프록시
• proxyTargetClass=true : CGLIB, 구체 클래스 기반 프록시, 인터페이스 여부와 상관없음

정리

• 프록시 팩토리의 서비스 추상화 덕분에 구체적인 CGLIB , JDK 동적 프록시 기술에 의존하지 않고 매우 편리하게 동적 프록시를 생성할 수 있다.
• 프록시의 부가 기능 로직도 특정 기술에 종속적이지 않게 Advice 하나로 편리하게 사용할 수 있었다. 이것은 프록시 팩토리가 내부에서 JDK 동적 프록시인 경우 InvocationHandler 가 Advice를 호출하도록 개발해두고, CGLIB인 경우 MethodInterceptor 가 Advice 를 호출하도록 기능을 개발해두었기 때문이다.

참고

스프링 부트는 AOP를 적용할때 기본적으로 proxyTargetClass=true 로 설정해서 사용한다.

따라서 인터페이스가 있어도 항상 CGLIB를 사용해서 구체클래스를 기반으로 프록시를 생성한다.****