이번 시간에는 지난 시간에 이어서 request 스코프 관련 에러가 났을 때 Provider를 통해서 해결하는 시간을 가졌다.
이전 시간에 다룬 내용을 아래 게시글 참고!
[섹션 9. 빈 스코프] 웹 스코프 & request 스코프 예제 만들기 / 인프런 김영한 스프링 핵심 원리 기
이번 시간에는 웹 스코프에 대해서 알아보았다. 지난 시간까지 싱글톤과 프로토타입 스코프를 배웠다. 싱글톤은 스프링 컨테이너의 시작과 끝까지 함께하는 긴 스코프이고, 프로토타입은 생성
easpop.tistory.com
첫번째 코드에서, 아래 코드와 같이 코드를 수정해준다.
이렇게 하면 MyLogger를 주입받는게 아닌, MyLogger를 찾을 수 있는 dependency Lookup을 할 수 있는게 주입이 된다.
그렇기 때문에 스프링이 생성되는 시점에 주입을 받을 수 있다.
그리고 이전에 다뤘던 코드에서 23번째 라인을 getObject를 통해서 받는 코드로 수정한다.
서비스단도 마찬가지로, Provider로 수정해준다.
이렇게 수정을 하면, 컨트롤러에서 http 요청이 들어온 시점에서 myLogger를 호출하기 때문에,
오류가 발생하지 않을 것이다.
서버가 정상적으로 올라왔다!ㅋㅋㅋㅋ
세팅해둔 URL로 요청을 해보자.
콘솔에 찍힌 로그를 확인해보면, 빈이 생성되고 소멸되는 과정을 확인할 수 있다.
[] <- 이 안에는 UUID 가 찍힌것을 볼 수 있고, 전부 동일한 고객이 요청한 것을 확인할 수 있다.
브라우저에서 새로고침을 눌러서 요청을 새로하게 되면 다른 UUID가 생성된 것을 볼 수 있다.
그리고 다르게 생성된 UUID로 요청을 구분할 수 있다.
http 요청이 들어오고 컨트롤러에서 getObject를 하는 시점에서 myLogger 객체가 생성이 된다.
중요한 점은, 동시에 여러 요청이 오더라도 요청마다 각각 객체를 따로 관리해준다는 점이다.
그렇기 때문에, 요청이 섞여도 구분할 수 있고, 요청이 많아도 스프링이 빈을 각각 다 할당해서 관리를 해준다.
정리를 하자면, ObjectProvider 덕분에 ObjectProvider.getObject() 를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있다. (정확히는 스프링 컨테이너한테 요청하는 것을 지연하는 것)
ObjectProvider.getObject()를 호출하는 시점에는 http 요청이 진행중이므로, request scope 빈의 생성이 정상처리 된다.
ObjectProvider.getObject()를 LogDemoController에서, LogDemoService 에서 각각 한번씩 따로 호출해도,
같은 http 요청이면 같은 스프링 빈이 반환된다.
쉽게 말해서, 컨트롤러에서 요청하든, 서비스에서 요청하든, 같은 빈 객체를 반환한다는 것이다.
댓글