빈 스코프, 웹 스코프, request 스코프 예제 만들기, 스코프와 Provider, 스코프와 프록시

  출처 : 인프런 - 스프링 핵심원리 - 기본편(유료) / 김영한님  
  유료 강의이므로 정리에 초점을 두고 코드는 일부만 인용  

https://inf.run/kCYMv

---

1. 웹 스코프

(1) 웹 스코프의 특징

• 웹 환경에서만 동작하며 스프링이 해당 스코프의 종료 시점까지 관리하므로 종료 메서드가 호출됨

(2) 웹 스코프의 종류

• request:  HTTP요청 하나가 들어오고 나갈 때 까지 유지되며 각각의 HTTP요청 마다 별도의 빈 인스턴스가 생성되고 관리됨
• session: HTTP Session과 동일한 생명주기를 가짐
• application: 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가짐
• websocket: 웹 소켓과 동일한 생명주기를 가짐
• 세션, 서블릿 컨텍스트, 웹소켓 같은 용어에 대한 지식은 웹 관련 공부를 별도로 진행

(3) HTTP request요청 당 각각 할당되는 request스코프

• 클라이언트A와 B의 요청이 각각 있을 때마다 각 클라이언트 전용의 객체가 생성되고 관리되며 클라이언트에 따라 동일한 객체가 반환됨

클라이언트의 요청마다 각각 할당되는 request 스코프

---

2. request 스코프 예제 만들기

1) 웹 환경 추가

(1) build.gradle 설정 추가

• 웹 환경에서만 동작하기 떄문에 web환경이 동작 하도록 라이브러리 추가
• hello.core.CoreApplication을 실행하면 웹 애플리케이션이 동작하고 localhost:8080에 접속하면 정상 동작함

//web 라이브러리 추가
implementation 'org.springframework.boot:spring-boot-starter-web'

 

** 참고

• spring-boot-starter-web 라이브러리를 추가하면 스프링부트가 내장 톰켓 서버를 활용하여 웹 서버와 스프링을 함께 실행함
• 스프링부트는 웹 라이브러리가 없으면 지금까지 학습한 AnnotationConfigApplicationContext를 기반으로 애플리케이션을 구동하지만 웹 라이브러리가 추가 되면 웹과 관련된 추가 환경들이 필요하여 AnnotationConfigServletWebServerApplicationContext를 기반으로 애플리케이션이 구동됨
• 만약 기본 포트인 8080포트가 다른곳에서 사용중이라면 포트를 변경하거나 8080포트를 죽여야함, 만약 9090포트로 변경하려면 application.properties에 아래의 설정을 추가하면됨

server.port=9090

2) request 스코프 예제 개발

(1) 예제 요구사항

• 동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분 하기 어려운데 이럴때 request 스코프를 사용하면 좋음
• 아래의 요구사항을 만족하는 추가 기능을 개발
• 기대하는 공통 포멧 : UUID {message} 
• UUID를 사용해서 HTTP 요청을 구분
• requestURL 정보도 추가로 넣어서 어떤 URL을 요청해서 남은 로그인지 확인

로그 예시
[d06b992f...] request scope bean create
[d06b992f...][http://localhost:8080/log-demo] controller test
[d06b992f...][http://localhost:8080/log-demo] service id = testId
[d06b992f...] request scope bean close

 

(2) MyLogger 생성

• main의 하위에 common 패키지를 만들어서 작성
• 로그를 출력하기 위한 MyLogger 클래스
• @Scope를 request로 지정하여 HTTP요청 당 하나씩 빈이 생성되고 HTTP요청이 끝나는 시점에 소멸함
• @PostConstruct 초기화 메서드를 사용하여 빈이 생성되는 시점에 uuid를 생성해서 저장함
• 빈이 HTTP 요청 당 하나씩 생성되므로 uuid를 저장해두면 다른 HTTP요청과 구분할 수 있음
• @PreDestroy를 사용해서 빈 소멸 시점에 종료 메세지를 남김
• requestURL은 이 빈이 생성되는 시점에는 알 수 없으므로 외부에서 setter로 입력 받음

package hello.core.common;

@Component
@Scope(value = "request") // value는 뺴도 됨
public class MyLogger {

    private String uuid;
    private String requestURL;

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

    public void log(String message) {
        System.out.println("[" + uuid + "]" + "["+requestURL+"] " + message); // 출력 포멧 설정
    }

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

    @PreDestroy
    public void close() {
        System.out.println("[" + uuid + "] request scope bean close: " + this);
    }
}

 

(3) LogDemoController

• web 패키지를 생성후 코드를 작성
• 로거가 잘 작동하는지 확인하는 테스트용 컨트롤러
• HttpSevletRequest를 통해 요청 URL를 받음
• request URL값 : http://localhost:8080/log-demo
• 이렇게 받은 requestURL 값을 myLogger에 저장
• mylogger는 HTTP요청당 각각 구분 되어 값이 섞이지 않음
• 컨트롤러에서 controller test라는 로그를 남김

** 참고

• 예제를 단순화하고 스프링 인터셉터를 학습하지 않았기에 requestURL을 Mylogger에 저장하는 부분을 컨트롤러에서 구현함
• 스프링 웹에 익숙하다면 공통처리가 가능한 스프링 인터셉터나 서블릿 필터 같은 곳을 활용하는 것이 좋음
• 강의는 2020년도 강의에 스프링부트 2.x버전이므로 @Controller에 메서드에 @RequestMapping, @ResponseBody를 사용하였으나 실습에서는 스프링 부트 3.x 버전이므로 @RestController와 @GetMapping으로 대체함

package hello.core.web;

@RestController
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    private final MyLogger myLogger;

    @GetMapping("log-demo")
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);

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

}

 

(4) LogDemoService

• logdemo패키지를 만들어서 작성
• 비즈니스 로직이 있는 서비스 계층에서도 로그를 출력하도록 myLogger.log()를 호출
• 여기서 중요한 점은 request scope를 사용하지 않고 파라미터로 모든 정보를 서비스 계층에 넘긴다면 파라미터가 많아서 지저분해 지고 requestURL 같은 웹 관련된 정보가 웹과 관련없는 서비스 계층까지 넘어가게 됨
• 웹과 관련된 부분은 컨트롤러까지만 사용하고 서비스 계층은 웹 기술에 종속되지 않고 가급적 순수하게 유지하는 것이 유지보수 관점에서 좋음
• request scope의 MyLogger 덕분에 파라미터로 넘기지 않고 MyLogger멤버변수에 저장해서 코드와 계층을 깔끔하게 유지가 가능하게 됨

package hello.core.logdemo;

@Service
@RequiredArgsConstructor
public class LogDemoService {
    
    private final MyLogger myLogger;

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

 

(5) 실행시 오류 발생

• 실행해보면 기대와는 다르게 오류가 발생함
• 스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만 request 스코프 빈은 실은 아직 생성되지 않았음
• request 스코프 빈은 실제 고객의 요청이 와야 생성할 수 있음

Error creating bean with name 'myLogger': Scope 'request' is not active for the
current thread; consider defining a scoped proxy for this bean if you intend to
refer to it from a singleton;

 

---

3. 스코프와 Provider

1) ObjectProvider를 적용하여 문제 해결

(1) LogDemoController 수정

• ObjectProvider를 적용하여 ObjectProvider.getObject()를 호출하는 시점까지 request scope빈의 생성을 지연시킴
• ObjectProvider.getObject()를 호출하는 시점에는 HTTP 요청이 진행중이므로 request scope 빈의 생성이 정상 처리됨

package hello.core.web;

@RestController
@RequiredArgsConstructor
public class LogDemoController {

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

    @GetMapping("log-demo")
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();

        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.setRequestURL(requestURL);

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

 

(2) LogDemoService 수정

• ObjectProvider를 적용

package hello.core.logdemo;

@Service
@RequiredArgsConstructor
public class LogDemoService {

    private final ObjectProvider<MyLogger> myLoggerProvider;

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

 

(3) 적용 후 실행

• 해당 코드를 적용하고 localhost:8080/log-demo에 접속하면 정상적으로 작동함
• LogDemoController와 LogDemoService에서 각각 따로 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환 됨

---

4. 스코프와 프록시

1) 프록시 방식 적용

(1) MyLogger 수정

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

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
    // 기존 코드 동일
}

 

(2) Controller와 Service의 코드를 원래대로 복구 후 실행

• LogDemoService의 코드와 LogDemoController의 코드를 ObjectProvider를 사용하기전의 코드로 원상 복구시킨 후 애플리케이션을 동작해보면 정상적으로 애플리케이션이 구동됨
• ObjectProvider를 사용했을 때에는 원본 코드를 수정해야했는데 프록시를 사용했더니 원본 코드의 수정없이도 문제가 해결되었음

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

(1) LogDemoController 수정

• 주입된 myLogger의 클래스정보를 확인해보기위해 LogDemoController에 myLogger.getClass()로 클래스 정보를 출력

System.out.println("myLogger = " + myLogger.getClass());

 

(2) 출력결과

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

myLogger = class hello.core.common.MyLogger$$SpringCGLIB$$0

 

(3) 가짜 프록시 객체의 위임로직

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

(4) 동작 정리

• CGLIB라는 라이브러리로 내 클래스를 상속받은 가짜 프록시 객체를 만들어서 의존관게를 주입함
• 가짜 프록시 객체는 실제 요청이 오면 내부에서 실제 빈을 요청하는 위임 로직이 들어있음
• 클라이언트가 myLogger.log()를 호출하면 가짜 프록시 객체의 메서드가 호출 됨
• 가짜 프록시 객체는 실제 request scope와는 관계가 없고 내부에 단순한 위임 로직만 있으며 싱글톤 처럼 동작함

(5) 특징 정리

• 프록시 객체 덕분에 클라이언트가 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있음
• Provider를 사용하든 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연차리 한다는 것임
• 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체하는 것이 다형성과 DI컨테이너가 가진 큰 장점임
• 웹 스코프가 아니더라도 프록시는 사용할 수 있음

(6) 주의점

• 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 주의해서 사용해야함
• 이렇게 특별한 scpoe는 무분별하게 사용하면 유지보수가 어려워지기 때문에 꼭 필요한 곳에만 최소화에서 사용해야함