[스프링 핵심 원리 - 기본편] 9강 - 빈 스코프(2)

*이 글은 개인적인 공부/기록 목적으로 올립니다.

부족하다고 느껴질 수 있는 글이니 양해 부탁드립니다.*

 

참고 영상/저작권

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 - 인프런 | 강의

---

■ 웹 스코프란?

• 웹 스코프는 웹 환경에서만 동작한다.
• 웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다.
  따라서 종료 메서드가 호출된다.

웹 스코프 종류

• request : HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다
  별도의 빈 인스턴스가 생성되고, 관리된다.
• session : HTTP Session과 동일한 생명주기를 가지는 스코프
• application : 서블릿 컨텍스트( ServletContext )와 동일한 생명주기를 가지는 스코프
• websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프

스프링 부트는 웹 라이브러리가 없으면 AnnotationConfigApplicationContext을
기반으로 애플리케이션을 구동한다.
웹 라이브러리가 추가되면 웹과 관련된 추가 설정과 환경들이 필요하므로
AnnotationConfigServletWebServerApplicationContext를 기반으로
애플리케이션을 구동한다.

---

■ request 스코프 예제

• 동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다.
  이럴때 사용하기 딱 좋은것이 바로 request 스코프이다.
• 다음과 같이 로그가 남도록 request 스코프를 활용해서 추가 기능을 개발해보자.

[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

• 기대하는 공통 포멧 : [UUID][requestURL]{message}
• UUID를 사용해서 HTTP 요청을 구분하자.
• requestURL정보도 추가로 넣어서 어떤 URL을 요청해서 남은 로그인지 확인하자.

@Component
@Scope(value = "request")
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 created: " + this);
  }

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

• request스코프이기 때문에 HTTP 요청마다 빈이 생성되고 소멸될 것이다.
• 이 빈이 생성되는 시점에 자동으로 @PostConstruct 초기화 메서드를 사용해서
  uuid를 생성해서 저장해둔다. 이 빈은 HTTP요청 당 하나씩 생성되므로,
  uuid를 저장해두면 다른 HTTP요청과 구분할 수 있다.
• 빈이 소멸되는 시점에는 @PreDestroy 를 사용해 종료 메시지를 남긴다.
• requestURL은 빈이 생성되는 시점에는 알 수 없어 외부에서 setter로 입력받는다.

@Controller
@RequiredArgsConstructor
public class LogDemoController {

  private final LogDemoService logDemoService;
  private final MyLogger myLogger;

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

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

• 로거가 잘 작동하는지 확인하는 테스트용 컨트롤러다.
• 받은 requestURL값을 myLogger 에 저장해둔다. myLogger 는 HTTP 요청 당 각각 구분되므로
  다른 HTTP 요청 때문에 값이 섞이는 걱정은 하지 않아도 된다.

requestURL 을 MyLogger 에 저장하는 부분은 컨트롤러 보다는
공통 처리가 가능한 스프링 인터셉터나 서블릿 필터 같은 곳을 활용하는 것이 좋다.

 

@Service
@RequiredArgsConstructor
public class LogDemoService {

    private final MyLogger myLogger;

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

• 서비스 계층에서도 로그를 출력해보자.
• 여기서 중요한 점이 있다. request scope를 사용하지 않고 파라미터로 이 모든 정보를
  서비스 계층에 넘긴다면, 파라미터가 많아서 지저분해진다.
  더 문제는 requestURL 같은 웹과 관련된 정보가 웹과 관련없는 서비스 계층까지 넘어가게 된다.
• request scope의 MyLogger 덕분에 이런 부분을 파라미터로 넘기지 않고,
  MyLogger 의 멤버변수에 저장해서 코드와 계층을 깔끔하게 유지할 수 있다.

웹과 관련된 부분은 컨트롤러까지만 사용해야 한다.
서비스 계층은 웹 기술에 종속되지 않고,
가급적 순수하게 유지하는 것이 유지보수 관점에서 좋다.

애플리케이션 실행 시점에 오류 발생

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;

request 스코프 빈은 실제 HTTP 요청이 있을 때 빈을 생성하므로

MyLogger를 주입받을 수 없어서 실패하는 것이다.

---

■ 스코프와 Provider

첫번째 해결방안은 앞서 배운 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.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);
        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
      }
}

@Service
@RequiredArgsConstructor
public class LogDemoService {

      private final ObjectProvider<MyLogger> myLoggerProvider;

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

• ObjectProvider 덕분에 ObjectProvider.getObject()를 호출하는 시점까지
  request scope 빈의 생성을 지연할 수 있다.
• ObjectProvider.getObject()를 호출하시는 시점에는 HTTP 요청이 진행중이므로
  request scope 빈의 생성이 정상 처리된다.

ObjectProvider.getObject()를 LogDemoController , LogDemoService 에서
각각 한번씩 따로 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환된다!

---

■ 스코프와 프록시

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
    ...
}

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

동작 원리

• CGLIB 라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
• 결과를 확인해보면 우리가 등록한 순수한 MyLogger클래스가 아니라
  MyLogger$$EnhancerBySpringCGLIB 이라는 클래스로 만들어진 객체가
  대신 등록된 것을 확인할 수 있다.
• ac.getBean("myLogger", MyLogger.class)로 조회해도 프록시 객체가 조회되는 것을 확인할 수 있다.

• 가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.
• 가짜 프록시 객체는 내부에 진짜 myLogger를 찾는 방법을 알고 있다.
• 클라이언트가 myLogger.logic()을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것이다.
  가짜 프록시 객체는 request 스코프의 진짜 myLogger.logic() 를 호출한다.

가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는
클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있다.
(다형성)

주의점

• 마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
• 이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자. 무분별하게 사용하면 유지보수하기 어려워진다.