이번에는 프록시 방식을 사용해보자.
@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}
proxyMode = ScopedProxyMode.TARGET_CLASS 를 추가해주자. TARGET_CLASS 를 선택INTERFACES 를 선택이제 나머지 코드는 Provider 사용 이전으로 돌려도 된다.
실행해보면 잘 동작하는것을 확인할 수 있다.
코드를 잘 보면 LogDemoController , LogDemoService 는 Provider 사용 전과 완전히 동일하다. 어떻게된 것일까?
웹 스코프와 프록시 동작 원리
먼저 주입된 myLogger를 확인해보자.
System.out.println("myLogger = " + myLogger.getClass());
출력결과
myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d
CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
@Scope 의 proxyMode = ScopedProxyMode.TARGET_CLASS) 를 설정하면 스프링 컨테이너는 CGLIB 라는 바이트코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성한다.
결과를 확인해보면 우리가 등록한 순수한 MyLogger 클래스가 아니라 MyLogger$$EnhancerBySpringCGLIB 이라는 클래스로 만들어진 객체가 대신 등록된 것을 확인할 수 있다.
그리고 스프링 컨테이너에 "myLogger"라는 이름으로 진짜 대신에 이 가짜 프록시 객체를 등록한다.
ac.getBean("myLogger", MyLogger.class) 로 조회해도 프록시 객체가 조회되는 것을 확인할 수 있다.
그래서 의존관계 주입도 이 가짜 프록시 객체가 주입된다.

가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.
myLogger.logic()을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것이다.myLogger.logic()를 호출한다.동작 정리
특징 정리
주의점