singleton, prototype 처럼 @Scope를 통해 request 객체를 지정해줄 수 있다.
request 객체는 Http 요청이 발생하면 생성되는 객체이다.
각 요청마다 하나씩 생성되기 때문에 수많은 요청이 들어와도 request 객체를 통해 전부 구분할 수 있다.
하지만 코드를 짤 때 아무런 조치도 취하지 않고 @Scope(value = "request") 처리만 해놓으면 서버가 제대로 동작하지 않는다.
말했듯이 request 객체는 Http 요청이 발생할 때 생성되는 객체인데 서버를 막 띄운 상태에서는 어떠한 Http 요청도 들어오지 않은 상태이기 때문이다.
즉, 생성된 request 객체는 없는데 request 객체에 의존성을 가진 Controller, Service 등의 클래스들이 컴포넌트 스캔의 대상이 되어 DI를 실행할 때 문제가 생기는 것이다.
이를 두 가지 방식으로 해결할 수 있다.
1. ObjectProvider<T>
request 객체에 의존성을 띈 모든 코드에 request 객체 대신 ObjectProvider를 두고 request 객체 사용 로직에서는 provider.getObject() 로 객체를 받아서 사용하는 것이다.
2. Proxy (이걸 더 많이 사용하는 듯)
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
(타겟의 형태에 따라서 TARGET_CLASS or INTERFACES 선택)
이렇게 하면 Http 요청 발생 여부와 관계 없이 request 클래스를 상속받은 가짜 프록시 클래스의 객체를(CGLIB) 생성하여 request 객체에 의존성을 가진 다른 빈에 대해서 DI를 실시한다.
request 객체를 사용하는 로직에서는 호출 시점에 진짜 request 객체를 찾아서 사용한다.
(진짜 request 객체를 찾아내는 로직은 가짜 프록시 객체 내부에서 진행된다.)
Proxy를 사용하면 어노테이션 설정 변경만으로 request 객체를 마치 싱글톤 객체를 사용하는 것처럼 사용할 수 있다.
(하지만 진짜 reqeust 객체는 Http 요청마다 생성되는 것이기 때문에 실제로는 여러 개가 존재)
@Scope의 무분별한 사용을 경계해야 한다.
유지보수에 큰 장애가 될 수 있으니 꼭 필요한 곳에서만 사용하자
'김영한님 스프링 강의 정리 > 핵심원리 기본편' 카테고리의 다른 글
빈 스코프 @Scope, ObjectProvider<T> (0) | 2021.01.16 |
---|---|
빈 생명주기 콜백 (0) | 2021.01.15 |
조회한 빈이 두 개 이상일 때? 필드명, @Qualifier, @Primary (0) | 2021.01.11 |
Lombok 라이브러리를 사용한 생성자 주입 (0) | 2021.01.11 |
의존성 주입 @Autowired, 옵션 처리 설정 (0) | 2021.01.11 |