일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- 코틀린
- Private
- Git
- git push
- GitHub
- open ai key 발급
- Public
- assertThat()
- JVM
- 캡슐화
- 표준함수
- 다음 큰 숫자 풀이
- 접근 제어자
- git pull
- apply
- @SpringBootApplication
- springboot
- 프로그래머스 #lv0
- static
- CLI
- git commit -m
- 싱글톤
- java
- JIT
- 인터프리터
- @Configuration
- git add
- streamlit
- 프로필 구현
- git clone
- Today
- Total
우당탕탕 개발_𝒍𝒐𝒈
<DI 컨테이너> @ComponentScan과 @Configuration은 반드시 함께 명시해야하는 걸까? 본문
spring 과정이 시작되었다.
지금까지는 Gradle을 사용하여 프로젝트를 진행하였고 그러다 막히는 부분이 있으면 그때그때 구글링을 통해 코드를 짜며 스프링에 대해 가볍게 공부를 했다.
그래서 스프링의 기본 동작 원리에 대해 깊게 고민을 해 본적이 없었는데 이번 수업을 통해 그동안 놓치고 있던 부분들에 대한 궁금증이 생기기 시작했다.
특히, 아무런 생각없이 클래스에 어노테이션을 달고 라이브러리를 적용시켜 왔던 과정에 대해 하나하나 '이것을 왜 여기에 사용했지?"라는 의문이 들기 시작했다.
그래서 오늘은
수많은 의문들 중 Spring Security를 적용할 때 사용했던 @ComponentScan 과 @Configuration에 대해 파헤쳐보려 한다.
1. Bean의 생성과 관리
나의 의문을 완전히 이해하기 위해서는 DI 컨테이너에 Bean을 등록하는 과정들에 대한 이해가 첫 번째라고 생각하였다.
우선 위 그림은 메이븐의 의존 그래프이다 BeanFactrory과 관계를 가진 더 많은 interface들이 있지만 우선 생략하고 핵심적인 클래스들만 남겼다.
위 그래프를 토대로 스프링 컨테이너가 Bean을 등록하는 과정을 간단히 살펴보자!
1.Bean 정의
자바 설정 클래스 = Annotation Config Application Context
XML 설정 클래스 = Generic Xml Application Context
그루비 스크립트 = Generic Groovy Application Context에서 각각 빈을 정의한다.
2. ComponantScan 진행
위에서 정의된 Bean은 스프링부트애플리케이션이 실행됨과 동시에 ComponantScan에 의해 자동 스캔되어 DI컨테이너에 의해 해석되어 객체의 생성, 검색, 초기화등의 기능이 수행된다.
-> 이때 ComponantScan의 스탠대상은 @Service , @repository 등의 역할을 명시하는 어노테이션이 붙은 클래스와 사용자가 직접 Bean을 등록한 @Configuration 클래스이다.
3.DI 컨테이너에서의 Bean관리
ComponantScan을 통해 등록된 Bean들은 DI컨테이너에 의해 관리된다. DI 컨테이너는 애플리케이션이 실행되는 동안 Bean을 생성, 초기화 주입하며 애플리케이션이 필요로 하는 의존성을 자동으로 연결한다.
나의 오해
@Configuration / 사용자가 설정한 클래스임으로 ComponantScan이 못 읽을 수 있어 @Configuration 어노테이션을 가진 클래스는 반드시 함께 @ComponantScan을 사용해야 한다.라고 생각했는데... 내가 적은 Spring Security클래스를 보면... @Configuration 만 적혀있고 정상적으로 작동되는 것을 확인했다...
분명 같이 사용해야 하는 거 아니었어..?
그렇다 @Configuration 클래스에서 @ComponantScan이 함께 할까 말까의 조건은 @Configuration 클래스가 @SpringBootApplication 같은 또는 하위 패키지로 연결되어 있는가?로 볼 수 있다.
그래서 내 프로젝트에서 @SpringBootApplication이 어디에 위치되어 있는지 찾아보았다.. 왜냐면 난 이 어노테이션을 작성한 기억이 없다!
timebean 패키지 가장 하단에 위치한 클래스...
처음부터 만들어져 있길래 사실 부끄럽지만 신경 쓰지 않았던 클래스...
그런데 혹시.. 하는 마음으로 들어가 보니
찾아버렸다,.. @SpringBootApplication을..
그렇다 나는 Spring Boot Starter을 사용하여 프로젝트를 생성했기에 너무 친절하게도 @SpringBootApplication이 붙은 클래스를 나 대신 만들어 준 것이다!
원래는 @SpringBootApplication이 붙은 클래스를 직접 작성하여 애플리케이션의 진입점을 정의할 수 있다.
@SpringBootApplication은 @configuration의 어노테이션을 포함하고 있어 @configuration가 명시되어있지 않아도 같은 하위 클래스의 bean을 스캔해준다고 한다.
따라서
Spring Security클래스와 @SpringBootApplication을 가진 TimebeanApplication클래스가 동일 패키지에 위치해 있었기 때문에 Spring Security클래스에 @Configuration어노테이션만 명시했어도 스캔의 대상이 되었던 것이었다!!
누군가에겐 사소한 고민이었겠지만
평소에 인지하고 있지 않았던 부분이었기에 공부를 할 때 상당히 흥미로웠다!
덕분에 Bean이 어떻게 생성되고 의존성이 어떤 방식으로 주입되는지에 대한 기본적인 동작방법을 알 수 있었다.
앞으로도 사소하지만 중요한 개념들을 잘 찾아보자!!
'대외 활동 > 데브코스' 카테고리의 다른 글
kotlin) 표준함수 이론 정리와 고민에 대한 생각의 과정 (5) | 2024.10.16 |
---|---|
singleton 패턴 (0) | 2024.07.20 |
static에 대해서 (0) | 2024.07.20 |
JVM 실행 과정/구성 요소 (1) | 2024.07.17 |
프로세스와 스레드 (0) | 2024.07.16 |