빈 스코프, Provider

Spring/Spring
2021. 11. 12.

이 게시글은 인프런 영한님의 강의를 듣고 복습하며 정리한 글입니다.

빈 스코프란?

빈 스코프는 '빈이 존재할 수 있는 범위'를 의미한다. 빈이 존재할 수 있는 범위에 따라서 여러 형태의 빈 스코프로 나누어지게 된다. 빈 스코프는 여러가지가 있는데, 아래 정도로 간략히 나눌 수 있다.

싱글톤 : 기본 스코프. 스프링 컨테이너 시작부터 종료까지 유지되는 스코프. 가장 넓은 범위
프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성, 의존관계 주입, 초기화 메서드까지만 관여. 클라이언트에게 빈을 반환 후, 이후 관리는 클라이언트에서만 관리한다. 따라서 종료 메서드가 호출되지 않는다.
Request : 클라이언트로부터 Http 요청이 들어오고 나갈 때까지만 유지되는 빈.

프로토타입 스코프란?

싱글톤 스코프는 항상 같은 빈을 반환한다. 반면에 프로토타입 스코프는 빈을 조회하면, 항상 새로운 인스턴스를 생성해서 반환해준다. 프로토타입 스코프의 핵심은 스프링 컨테이너는 인스턴스 생성 + DI + 초기화 메서드까지만 하고, 나머지는 관여하지 않는다는 점이다. 따라서 소멸 콜백함수는 사용되지 않는다.

프로토타입 빈 스코프 설정

// 수동 빈등록
@Scope("prototype")
@Bean

// 자동 빈등록
@Scope("prototype")
@Component

프로토 타입을 등록할 때는 @Component, @Bean 위에 @Scope 어노테이션을 달아주고 "prototype"을 작성해주면 된다.

프로토타입 스코프 vs 싱글톤 스코프

싱글톤 빈은 스프링 컨테이너의 빈 저장소에 빈 객체를 생성하고 관리한다. 클라이언트에서 조회 요청이 오면, 항상 동일한 빈 객체를 꺼내서 클라이언트에게 반환해준다.

프로토타입은 각 클라이언트가 빈을 조회하면, 조회할 때 마다 새로운 빈을 생성 + 의존관계 주입 + 초기화 메서드까지 실행을 한다. 세 번 조회 요청이 오면, 세 번 다른 인스턴스가 생성된다.

생성되고 의존관계 주입, 그리고 초기화 메서드까지 완료된 인스턴스는 클라이언트에게 반환된다. 그리고 그 빈 객체는 스프링 컨테이너의 빈 저장소에 더 이상 존재하지 않는다. 반환된 빈 객체의 관리 책임은 스프링 컨테이너가 아닌, 클라이언트에게 있다.

싱글톤 스코프 테스트

public class SingletonTypeTest {

    @Test
    void singletonTest(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SingletonBean.class);

        System.out.println("find bean1");
        SingletonBean singletonBean1 = ac.getBean(SingletonBean.class);

        System.out.println("find bean2");
        SingletonBean singletonBean2 = ac.getBean(SingletonBean.class);

        System.out.println("singletonBean1 = " + singletonBean1);
        System.out.println("singletonBean2 = " + singletonBean2);

        Assertions.assertThat(singletonBean1).isSameAs(singletonBean2);

        ac.close();

    }



    static class SingletonBean{
        @PostConstruct
        public void init(){
            System.out.println("SingletonBean.init");
        }
        @PreDestroy
        public void close(){
            System.out.println("SingletonBean.close");
        }
    }

}

위의 코드는 싱글톤 스코프 테스트 코드다. 싱글톤 스코프이기 때문에 초기화 콜백 함수, 소멸 콜백 함수(스프링 컨테이너 소멸 직전)가 모두 실행되어야 한다. 또한, 싱글톤 스코프는 요청할 때 마다 스프링 컨테이너의 빈 저장소에서 관리하는 싱글톤 객체를 반환하기 때문에 반환된 참조값들이 모두 같아야 한다.

위는 코드의 실행결과다. 싱글톤 스코프기 때문에 초기화는 단 한번만 되고, 소멸 함수 역시 실행 되었다. 그리고 각 싱글톤 빈 객체가 같은 참조값을 가지는 것을 알 수 있다.

프로토타입 스코프 테스트

public class ProtoTypeTest {



    @Test
    void test1(){

        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ProtoTypeBean.class);

        System.out.println("find protoTypeBean1");
        ProtoTypeBean protoTypeBean1 = ac.getBean(ProtoTypeBean.class);

        System.out.println("find protoTypeBean2");
        ProtoTypeBean protoTypeBean2 = ac.getBean(ProtoTypeBean.class);

        System.out.println("protoTypeBean1 = " + protoTypeBean1);
        System.out.println("protoTypeBean2 = " + protoTypeBean2);

        Assertions.assertThat(protoTypeBean1).isNotSameAs(protoTypeBean2);

        ac.close();
    }


    @Scope("prototype")
    static class ProtoTypeBean{

        @PostConstruct
        public void init(){
            System.out.println("ProtoTypeBean.init");
        }

        @PreDestroy
        public void close(){
            System.out.println("ProtoTypeBean.close");
        }
    }

}

위 코드는 프로토타입 테스트 코드다. 프로토타입 스코프기 때문에 클라이언트로 요청이 올 때 마다 새로운 인스턴스가 만들어지고, 의존관계 주입, 초기화 메서드까지 실행된다. 그리고 클라이언트에게 반환된다. 따라서 테스트 코드를 실행하면 클라이언트가 빈 객체를 요청할 때 마다 초기화 메서드가 실행될 것이고, 각 객체는 다른 참조를 가진다. 그리고 스프링 컨테이너에는 빈 객체가 더 이상 없기 때문에 스프링 컨테이너가 소멸될 때 소멸 콜백 함수는 호출되지 않는다.

위 코드의 실행 결과다. 초기화 콜백 함수가 2번 실행되었으며, 각 빈은 다른 참조값을 가지는 것을 확인했다. 그리고 소멸 콜백 함수는 실행되지 않았다.

싱글톤 스코프, 프로토타입 스코프를 함께 쓸 때 문제점

싱글톤 스코프와 프로토타입 스코프를 함께 사용한다면 문제점이 발생할 가능성이 높다. 왜냐하면 서로 다른 주기를 가지고 있기 때문에 함께 쓰이게 될 경우, 다른 스코프의 영향을 받을 수 있다. 예를 들어 싱글톤 스코프 클래스가 필드변수로 프로토타입 스코프 클래스를 가진다고 가정해보자.

이 경우는 문제가 발생할 수 밖에 없다. 왜냐하면 싱글톤 스코프는 스프링 컨테이너가 생성될 때 함께 생성되서, 스프링 컨테이너가 종료될 때 함께 소멸되는 빈 객체이기 때문이다. 싱글톤 스코프가 프로토타입 스코프 클래스를 필드 변수로 가지기 때문에 프로토타입 스코프를 가지는 빈 객체는 싱글톤 스코프가 최초로 생성될 때 단 한번만 생성되고 계속 유지된다. 그것이 비록 프로토타입 스코프라고 할지라도 말이다. 아래에 테스트 코드가 있다.

public class SingletonTypeTestWithProtoTyepBean {

    @Test
    void SingletonTestWithProto(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);

        ClientBean bean1 = ac.getBean(ClientBean.class);
        ClientBean bean2 = ac.getBean(ClientBean.class);

        int count1 = bean1.logic();
        int count2 = bean2.logic();

        System.out.println("count1 = " + count1);
        System.out.println("count2 = " + count2);

        Assertions.assertThat(count1).isNotEqualTo(count2);


    }


    @RequiredArgsConstructor
    @Scope("singleton")
    static class ClientBean{
        private final PrototypeBean prototypeBean;

        public int logic(){
            prototypeBean.addCount();
            return prototypeBean.getCount();
        }

        @PostConstruct
        public void initSingleton(){
            System.out.println("ClientBean.initSingleton");
        }

        @PreDestroy
        public void singltonend(){
            System.out.println("ClientBean.singltonend");
        }

    }


    @Scope("prototype")
    static class PrototypeBean {
        private int count = 0 ;

        public void addCount() {
            count++;

        }
        public int getCount(){
            return count;
        }

        @PostConstruct
        public void init(){
            System.out.println("PrototypeBean.init");
        }

        @PreDestroy
        public void destory(){
            System.out.println("PrototypeBean.destory");
        }
    }
}

프로토타입 스코프는 객체는 필드 변수로 count 값을 가지는데, 이 값은 addCount를 통해서 1개씩 늘릴 수 있다. 그리고 싱글톤 스코프 객체는 필드 변수로 프로토타입 스코프를 가지는데, 여기에는 Logic 메서드가 있다. Logic 메서드 내에는 AddCount()를 한번 한 후에, 그 Count값을 돌려주는 로직이 구현되어있다. 위 코드를 실행한 결과는 아래와 같다.

먼저 ClientBean이 먼저 생성된다. 생성자로 DI가 되기 때문에 이 시점에 PrototypeBean 빈 생성 + 의존관계 주입 + 초기화 메서드가 실행된 후, ClientBean으로 DI가 실행된다. 이후 ClientBean의 초기화 메서드가 실행된다. Bean1, Bean2로 객체를 가져오지만 동일한 싱글톤 참조를 가지기 때문에 ProtoType Bean 역시 동일하게 유지된다.

따라서, logic을 실행할 때 마다 같은 ProtoType 빈 객체의 값이 증가한다. 그래서 1,2가 각각 출력되는 것이다. ac.Close()를 하게 되면 Client 객체가 소멸 콜백 함수가 실행된다.

새로운 프로토타입 스코프 빈 객체 만드는 방법

그런데 프로토타입 스코프와 싱글톤 스코프를 같이 쓰는 것은 이런 결과를 생각하고 쓰는 것은 아닐 것이다. 각 싱글톤 스코프를 사용할 때 마다 새로운 프로토타입 스코프 빈 객체를 만들어서 각각 1을 반환하는 것이 목적일 것이다. 그렇다면 이럴 때는 어떻게 해야할까?

스프링 컨테이너로 프로토타입 빈을 꺼내오기

   @RequiredArgsConstructor
    @Scope("singleton")
    static class ClientBean{

        private final ApplicationContext ac;

        public int logic(){
            PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
            prototypeBean.addCount();
            return prototypeBean.getCount();
        }

        @PostConstruct
        public void init(){
            System.out.println("ClientBean.init");
        }


    }

싱글톤 스코프 빈은 스프링 컨테이너를 필드 변수로 가진다. 그래서 logic 메서드에 접근할 때마다, 스프링 컨테이너에서 PrototypeBean을 요청하고, 나머지 로직을 처리하는 방식이다. 이 방식은 logic 메서드에 접근할 때 마다 ProtoTypeBean을 요청하기 때문에 그 때 마다 프로토타입 빈이 스프링 컨테이너에서 생성되고, ClientBean으로 전달된다.

위는 검증 코드를 실행한 결과다. 먼저 ClientBean이 초기화가 완료된다. 그리고 로직이 들어오면 ProtoTypeBean이 하나 만들어진다. 두 번 로직을 요청했기 때문에 ProtoTypeBean은 2번 초기화 된다. 즉, 요청할 때 마다 만들어진다는 것이다.

그런데 위의 코드로 실행하게 되면, 만족하는 것은 실행했지만 스프링 컨테이너에 종속적인 코드가 된다. 왜냐하면 스프링 컨테이너 자체를 필드 변수로 받아서 이런 저런 것들을 실행하는 코드이기 때문이다. 스프링 컨테이너에 종속적인 코드라는 말은, 순수 자바코드나 다른 컨테이너에서는 단위 테스트가 어렵다는 말이다.

그렇다면 어떤 방법을 해야할까? 위에 있었던 프로토타입 빈을 찾는 것을 DI(Dependecny Injection)이 아닌 DL(Dependency LookUp, 의존관계 탐색)이라고 한다. 위 코드를 구현하기 위해서는 딱 DL 정도의 기능만 있으면 된다. 그렇다면 이 DL정도의 기능만 지원하는 것을 찾아서 해보면 될 것 같다.

ObjectFactory / ObjectProvider를 이용한 DL(Dependency LookUp)

지정한 빈을 컨테이너에서 찾아주는 DL(의존관계 탐색) 기능을 제공하는 것이 ObjectProvider라고 한다. ObjectFactory는 예전에 구현된 것이고, 편의 기능이 추가된 것이 ObjectProvider라고 한다. 사용은 아래처럼 하면 된다.

ObjectProvider 사용 방법

ObjectProvider Type을 선언한다
ObjectProvider 필드에 의존관계 주입을 해준다. (스프링 컨테이너에서 의존관계 주입이 필요)
ObjectProvider에 의존관계가 주입이 되면 getObject()로 필요한 객체를 DL하여 사용한다.

@Autowired
ObjectProvider<PrototypeBean> protoTypeBeanProvider;

protoTypeBeanProvider.getObject();

실제 위의 코드를 리팩토링 하면 아래와 같이 변경이 가능하다.

    @RequiredArgsConstructor
    @Scope("singleton")
    static class ClientBean{

        @Autowired
        private ObjectProvider<PrototypeBean> prototypeBeanObjectProvider;

        public int logic(){
            PrototypeBean prototypeBean = prototypeBeanObjectProvider.getObject();
            prototypeBean.addCount();
            return prototypeBean.getCount();
        }

prototypeBeanObjectProvider에 필드 주입을 하는 이유는 Provider에 의존관계 주입이 필요하기 때문이다. 만약에 @Autowired 없이 위 코드를 실행하게 되면, Provider에 주입된 값이 없기 때문에 Null Pointer Exception이 발생하는 것을 볼 수 있다.

아래 이미지에서 확인할 수 있듯이 ClientBean 생성 후, 초기화를 하는 과정에서 prototypeBeanProivder에 의존관계 주입이 되어야한다. 그런데 의존관계 주입이 되지 않았기 때문에 Logic 메서드에 들어간 직후 prototypeBeanProvider가 빈 것이 확인되어 NPE가 발생한다.

@Autowired로 prototypeBeanProvider에 의존관계 주입을 해서 알맞는 객체를 주입해주면 아래와 같이 깔끔하게 실행되는 것을 확인할 수 있다.

ObjectFactory / ObjectProvider 정리

스프링이 제공하는 기능을 사용하지만, 기능이 단순하기 때문에 단위 테스트를 만들거나 mock 코드를 만드는 것이 쉬움.
ObjectProvider.getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. (DL)
ObjectProvider는 딱 필요한 DL 정도의 기능만 제공한다.
스프링이 제공하는 기능이기 때문에 일부 스프링에 종속적이다.
ObjectProvider는 사용 시, 가져올 객체 타입을 지정해주어야 함.

JAVA 표준 Provider 사용 (JSR-330)

스프링에서 제공해주는 ObjectProvider와 비슷하게 자바 표준에서도 Provider를 제공해준다. 자바 표준에서 제공해주는 Provider를 사용하면 된다. JAVA 표준 Provider에 대한 특징은 아래와 같다.

get() 메서드 하나만 존재한다
gradle에 별도의 라이브러리 추가가 필요하다
자바 표준이므로 스프링 컨테이너가 아닌 다른 곳에서도 사용 가능하다.

JAVA 표준 Provider 라이브러리 추가 방법

implementation 'javax.inject:javax.inject:1'

build.grade의 dependency에 위 코드를 추가한 후, gradle 업데이트를 해준다.

JAVA 표준 Provider를 사용한 코드 리팩토링

이전에 ObjectProvider로 선언하던 것을 Provider Type으로 선언하면 된다. 이 때 조심해야 할 부분은 javax.inject가 제공하는 Provider<T>를 사용해야한다는 것이다. 그리고 Javax가 지원하는 Provider의 기능은 get()밖에 없기 때문에, get() 메서드를 사용해서 스프링 컨테이너에 있는 protoType Bean을 요청하면 된다.

실행 결과는 위처럼 ObjectProvider와 동일하게 나오는 것을 알 수 있다. ObjectProvider와 유사하게 동작하는 것으로 예상된다.

프로토타입 빈은 언제 사용해야 할까?

매번 사용할 때 마다 의존관계가 주입이 완료된 새로운 객체가 필요할 때 사용하면 된다고 한다. 그런데 실무에서 요구되는 많은 상황들은 대부분 싱글톤 빈으로 해결이 된다고 한다. 이런 이유로 인해 프로토타입 스코프 빈을 많이 사용하지는 않는다고 한다.

Object Provider vs JSR-330 뭘 써야하지?

기본적으로는 Object Provider를 사용하면 된다고 한다. OjbectProvider는 getObject()를 제외하고도 여러 편의 기능이 많이 제공되기 때문이다. 그렇기 때문에 Object Provider를 중점으로 사용하고, 스프링 컨테이너 외에 다른 컨테이너에서 사용이 필요할 때는 JSR-330을 사용하면 된다고 한다.

웹 스코프 (Request Scope)

앞서 이야기 했던 싱글톤 스코프는 스프링 컨테이너 생성되며 빈이 만들어지고, 스프링 컨테이너가 소멸될 때 빈이 없어진다. 프로토타입 스코프는 빈이 요청될 때 생성되서 초기화까지 완료된 후 스프링 컨테이너에서 반환되는 스코프다. 웹 스코프는 이와는 다르게 웹 요청이 오고 나갈 때까지만 빈이 유지되는 스코프를 이야기 한다.

웹 스코프의 특징은 아래와 같다.

웹 스코프는 웹 환경에서만 동작한다.

웹 스코프는 스프링이 해당 스코프의 종료 시점까지 관리한다. 즉, 종료 메서드가 호출된다.

웹 스코프의 종류는 Request, Session, Application, Websocket 등이 있는데, Request와 모두 동작 범위만 다르지 유사하게 동작한다고 한다.

프로토타입 스코프는 요청이 올 때 마다, 프로토타입 빈이 생성이 되고 스프링 컨테이너에서 삭제되었다. 웹 스코프는 웹 요청이 올 때 마다 스프링 컨테이너 내에 생성이 되고, 요청이 나가기 전까지는 스프링 컨테이너에서 계속 관리된다. 요청이 나가게 되면 스프링 컨테이너에서 관리되던 웹 스코프 빈은 삭제된다.

Request 스코프 만들어보기

STEP1. 웹 스코프는 웹 환경에서만 동작함. 웹 동작하도록 라이브러리 추가한다.

implementation 'org.springframework.boot:spring-boot-starter-web'

build.gradle의 dependencies에 위 코드를 추가해서 웹 가능하도록 라이브러리를 추가한다. 라이브러리 추가 후, Gradle refresh를 해준다. 웹 라이브러리를 추가하면 내장 톰캣 서버를 활용해서 웹 서버와 스프링을 함께 실행시킨다.

STEP2. 스프링 부트 실행해보기

스프링부트를 실행해보면 위처럼 내장 TomCat Server가 돌아가는 것을 알 수 있다. 그리고 localhost:8080으로 접속해보면 오른쪽과 같이 정상실행 된 것을 볼 수 있다.

참고

스프링부트는 웹 라이브러리가 없으면 기본적으로 'AnnotationConfigApplicationContext'를 기반으로 어플리케이션을 구동한다. 웹 라이브러리가 추가되면 웹과 관련된 추가적인 설정이 필요하다. 따라서 스프링부트는 'AnnotaionConfigServiceWebServiceApplicationContext"를 기반으로 어플리케이션을 구동하게 된다.

STEP3. Request 스코프 예제 개발

동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다. Request 스코프 예제 개발은 로그가 남도록 Request 스코프를 활용해서 기능을 개발한다. 로그 포멧은 아래 형식으로 나타낸다

[UUID][requestURL]{message}

STEP4. MyLogger 클래스 개발

request 스코프는 HTTP 요청이 올 때 마다 UUID가 생성되어야한다. 즉, HTTP 초기화 콜백 함수에서 UUID를 셋팅하도록 한다.

@Component
@Scope("request")
public class MyLogger {

    private String uuid;
    private String requestURL;

    public void setUuid(String uuid) {
        this.uuid = uuid;
    }

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message){
        System.out.println("[" + uuid + "][ " + requestURL + "]" + message);
    }


    @PostConstruct
    public void init(){
        this.uuid = UUID.randomUUID().toString();
        System.out.println("[" + this.uuid + "]" + "reqeust scope bean create" + this);
    }

    @PreDestroy
    public void destory(){
        System.out.println("MyLogger.destory");
    }

}

request Scope이기 때문에 @Scope(request)를 설정해주었다. 필드변수는 uuid, requestURL을 가진다. @ComponentScan의 대상이다. Default 생성자이기 때문에 생성하면서 필드 변수에는 어떤 의존관계도 주입되지 않는다. HTTP 요청이 오면, 위 인스턴스는 생성되는데 초기화 콜백 함수에서 UUID를 새로 만들어서 부여하게 된다. requestURL은 이 빈이 생성되는 시점에서는 알 수 없기 때문에, 추후 외부에서 수정한다.

STEP5. LogService 개발

package myname.core2.web;


import lombok.RequiredArgsConstructor;
import myname.core2.common.MyLogger;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class LogService {

    private final MyLogger myLogger;

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

Service에서도 동일한 HTTP 요청에 대해 동작하는지 확인하기 위해서 LogService를 만든다. @Service를 달아서 ComponentScan의 대상이 하게 해준다. 그리고 MyLogger 필드 변수를 가지게 하고, myLogger.log 메서드를 활용해서 현재 Service Id에 대해서 로그가 정상으로 찍히고 있는 것을 보여주도록 한다.

STEP6. LogController 개발

@Controller
@RequiredArgsConstructor
public class LogController {

    private final MyLogger myLogger;
    private final LogService logService;

    //HttpServeletRequest 형태로 값이 왔을 때
    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request){
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);

        myLogger.log("controller test");
        logService.logic("testId");
        return "OK";
    }
}

먼저 @Controller임을 명시해주고, Default 생성자를 통해 의존관계 주입을 해준다. 이 때, LogService가 들어간다.

"log-demo"에 매핑되는 메서드를 만드는데, 입력은 서블릿 Request 형태로 받도록 한다. 받은 Request에 대해 URL을 추출해서 setter를 통해서 MyLogger에 셋팅해준다. 이후 controller Test를 해서 값이 정상 출력되는지를 확인하고, logService에 값을 넘겨주어 Service가 정상으로 출력되는지도 확인해본다.

실행 결과

위 코드를 작성 후, 실행해보면 위 결과가 나온다. logController 빈을 생성하는데 문제가 있었다고 한다. 뒤를 좀 더 살펴보면 myLogger 필드 변수의 Scope가 request이기 때문에 현재 존재하지 않아 logController 빈을 생성하는데 문제가 생겼던 것으로 이해할 수 있다.

logController는 싱글톤 스코프로 스프링 컨테이너가 생성될 때 같이 생성되야 하는데, logController의 필드변수인 myLogger는 http 요청이 들어올 때마다 생성되는 빈이다. 즉, myLogger의 생성은 지연이 되어야한다. 이의 해결을 위해서 Provider를 활용할 수 있다.

STEP7-1. Provider를 이용한 request 스코프 빈 생성 지연

앞에서 있던 문제는 싱글톤 빈을 생성하는 시점에서 request 스코프 빈이 생성되지 않았기 때문에 빈이 정상적으로 등록되지 않았다는 문제다. 이의 해결을 위해서 앞서 사용했던 ObjectProvider를 활용해서 request 스코프 빈이 생성되는 시점을 지연시키면서 해결가능하다.

@Controller
@RequiredArgsConstructor
public class LogController {

    private final ObjectProvider<MyLogger> myLoggerObjectProvider;
    private final LogService logService;


    //HttpServeletRequest 형태로 값이 왔을 때

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

        myLogger.log("controller test");
        logService.logic("testId");
        return "OK";
    }
}

LogController 클래스에서는 필드 변수를 MyLogger를 가지고 있었는데, 대신 ObjectProvider를 필드변수로 가진다. 그리고 log-demo에 웹 요청이 왔을 때, ObjectProvider의 getObject() 메서드를 이용해 DL(Dependency Lookup)을 실행해서 스프링 컨테이너에게 MyLogger 빈 생성을 요청한다.

이 때 MyLogger 빈은 생성이 되고, logDemo 메서드 요청이 완료될 때까지 스프링 컨테이너에서 관리된다. 따라서, logService에서 getObject()를 하면 스프링 컨테이너에 저장되어있는 MyLogger 빈이 return 되면서 같은 참조를 가지고 처리를 할 수 있게 된다.

STEP7-2. Proxy Mode를 활용한 request 스코프 빈 생성 지연

ObjectProvider를 제외하고 Proxy Mode를 활용한 request 스코프 빈 생성을 지연하는 방법이 있다. scope에 proxy_mode를 설정해줄 수 있는데, 여기서 TARGET_CLASS(대상이 구현체) / TARGET_INTERFACES(대상이 인터페이스)로 설정해주면 된다.

Proxy Mode를 사용하게 되면, 초기화 되는 순간에는 진짜 구현체에 대한 빈이 생성되는 것이 아니다. CGLIB 라이브러리를 사용해서 구현체를 상속받은 가짜 라이브러리가 만들어져서 주입이 된다. 이 때, 가짜 프록시 객체에는 진짜 요청이 왔을 때 내부에서 진짜 빈을 요청하는 로직이 들어있다. 그래서 실제로 HTTP 요청이 와서 MyLogger가 필요한 순간에 MyLogger가 생성되서 주입된다.

위 이미지에서 요청이 오지 않았는데 myLogger에는 CGLIB 베이스로 만들어진 클래스가 들어있는 것이 getClass() 메서드로 확인된다. 이후 this로 표시되는 myLogger의 생성자 + 초기화 콜백 함수가 차례로 불러져서 myLogger가 스프링 컨테이너 빈에 등록이 되어 사용된다.

간단히 정리하면 아래와 같다.

1. myLogger.logic()은 사실 가짜 프록시 객체의 메서드를 호출한 것이다.

2. 가짜 프록시 빈은 내부에 myLogger의 참조값을 가지고 있으며, myLogger를 찾는 방법을 알고 있다.

3. 가짜 프록시 객체는 request 스코프 진짜 myLogger.logic()을 호출한다.

4. 가짜 프록시 객체는 myLogger를 상속받아 만들어졌기 때문에 클라이언트는 이것이 어떤 것인지 모르고 사용할 수 있다.(다형성)

myLogger는 가짜기 때문에 모든 것들이 공유해도 상관없다.(싱글톤 빈 생성 시 생성). 가짜 프록시 객체는 실제 request scope의 객체와는 아무런 관련이 없다. 그냥 가짜라고 보면 되고, 싱글톤 스코프처럼 동작하는 것으로 보면 된다.

동작을 정리하면 다음과 같다.

1. CGLIB라는 라이브러리를 활용해 내 클래스를 상속받은 가짜 프록시 객체를 만들어서 주입한다. 가짜이기 때문에 항상 싱글톤처럼 사용이 가능하고, 가짜이기 때문에 의존관계 주입 시에는 request scope와는 관련이 없다.

2. 이 가짜 프록시 객체는 실제 요청이 왔을 때, 내부적으로 진짜 객체를 찾는 위임 로직이 있다.

특징을 정리하면 아래와 같다.

1. 프록시 객체는 가짜기 때문에 싱글톤 빈을 사용하는 것처럼 편리하게 request Scope를 사용할 수 있다.

2. Provider / Proxy_Mode의 핵심 아이디어는 request Scope의 실제 빈 생성을 요청 시점까지 지연시킨다는데에 있다.

3. 어노테이션 하나만을 원복 객체를 프록시 객체로 대체할 수 있다. 이것이 DI 컨테이너와 다형성이 가지는 큰 장점이다. (클라이언트 코드를 전혀 고치지 않고 돌아간다는 것이 큰 장점이다)

주의점

1. 마치 싱글톤처럼 돌아간다고 싱글톤처럼 사용하면 안된다. request 스코프 객체는 호출될 때 마다 생성되고 있다.

2. 이런 특별한 스코프는 무분별하게 사용 시 유지 보수에 어려움이 있다.

저작자표시 비영리 변경금지

'Spring > Spring' 카테고리의 다른 글

Spring MVC : Error 관련 (0)	2022.01.06
@Autowired가 붙었을 때 (0)	2021.11.13
빈 생명주기 콜백 (0)	2021.11.12
빈 등록, 자동? 수동? 선택 기준은? (0)	2021.11.12
조회한 빈이 모두 필요할 때, List, Map (0)	2021.11.12

만년 꼴지 공대생 세상 이야기