스코프와 프록시

김원종·2023년 7월 19일

핵심포인트 proxyMode = ScopedProxyMode.TARGET_CLASS 를 추가해주자.
- 적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS 를 선택
- 적용 대상이 인터페이스면 INTERFACES 를 선택
이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.

이렇게 설정후 나머지 코드를 Provider 사용 이전으로 돌려두자

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    private final ObjectProvider<MyLogger> myLoggerProvider;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request){
        MyLogger myLogger = myLoggerProvider.getObject();
        String requestURL = request.getRequestURI().toString();
        myLogger.setRequestURL(requestURL);

        myLogger.log("controller test");
        logDemoService.logic("testID");

        return "OK";
    }
}

@Service
@RequiredArgsConstructor
public class LogDemoService {

    private final MyLogger myLogger;

    public void logic(String id) {
        myLogger.log("service id =" + id);
    }
}

이렇게 수정한 후 실행해보면 잘 동작하는것을 확인할 수 있다.
코드를 살펴보면 LogDemoController , LogDemoService는 Provider사용 전과 동일하게 구성되어있다. 이제 동작원리를 살펴보자.

웹 스코프와 프록시 동작 원리

CGLB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.

@Scope의 proxyMode = ScopedProxyMode.TARGET_CLASS 를 설정하면 스프링 컨테이너는 CGLIB라는 바이트 코드를 조작하는 라이브러리를 사용해서 MyLogger를 상속받은 가짜 프록시 객체를 생성한다.
결과를 확인해보면 우리가 등록한 순수한 MyLogger 클래스가 아니라 MyLogger$$EnhancerBySpringCGLIB이라는 클래스로 만들어진 객체가 대신 등록된 것을 확인할 수 있다.
그리고 스프링 컨테이너에 "myLogger"라는 이름으로 진짜 대신에 이 가짜 프록시 객체를 등록한다.
ac.getBean("myLogger",MyLogger.class) 로 조회해도 프록시 객체가 조회되는 것을 확인할 수 있다.
그래서 의존 관계 주입도 이 가짜 프록시 객체가 주입된다.

가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.

이 가짜 프록시 빈은 내부에 실제 MyLogger의 참조를 가지고 있다,
클라이언트가 myLogger.logic()을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것이다.
가짜 프록시 객체는 내부에 진짜 myLogger 를 찾는 방법을 알고 있다,
가짜 프록시 객체는 request스코프의 진짜 myLogger.logic() 를 호출한다.
가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게 , 동일하게 사용할 수 있다. (다형성)

동작 정리