스프링 컨테이너생성 과 Component Scan

스프링 컨테이너란?

스프링 컨테이너는 스프링에서 빈 들을 관리, 생성, 생명주기를 담당하는 역할을 한다

스프링 컨테이너의 생성과정은 크게 2가지로 나뉜다

 

스프링 컨테이너의 생성 과정

1. 설정 정보 (Config.class)를 보고 스프링 컨테이너가 빈들을 가져온다

    이때 수동주입, 자동주입으로 빈들을 가져온다

참고 : 부모 빈을 가져오면 거기에 딸린 모든 빈을 다 가져온다 (주렁주렁)

 

2. 이렇게 가져온 빈들의 의존관계를 설정한다

 

이 두 과정을 통해 스프링 컨테이너가 생성되고 빈들을 관리한다 

---

1. 스프링 컨테이너 생성(ApplicationContext와 BeanFactory)

사실 원래 빈을 관리하고 검색하는 기능은 BeanFactory가 제공한다

그리고 이 BeanFacory의 빈을 관리하는 기능 + 여러 가지 부가 편의 기능을 제공한 게 ApplicationContext 다 

여기서 부가기능은 MessageSource , 환경변수, 애플리케이션 이벤트, 편리한 리소스 조회 등이 있다 
궁금하면 한번 찾아보자!

 

 

보통 ApplicationContext를 스프링 컨테이너라고 한다

그리고 new AnnotationConfigApplicationContext("Config클래스")를 통해 컨테이너를 만든다

그럼 Config 클래스라는 게 뭘까..?

 

Configuration (Config 클래스)

Config 클래스는 스프링 컨테이너를 만들 때 어떤 빈을 가져와서 컨테이너에 등록할지 결정하는 역할을 담당한다

보통 일반 자바 클래스에 @Configuration 어노테이션을 붙여 만든다

 

빈을 가져오는 방법은 크게 두 가지가 있는데

1. config 클래스에 @Bean을 통해서 수동으로 빈을 등록하거나

2. @ComponentScan을 통해 자동으로 빈을 등록하는 방법이다 

 

결론적으로 Config class는 위 두 가지 방법으로 스프링 컨테이너에 어떤 빈을 등록할지 결정할 정보를 담은 class 다

이 Config 클래스를 통해 스프링 컨테이너에서 쓸 빈들을 가져온다

 

의존관계 주입 부분에선 설명할 부분이 많아서 나중에 글을 통해서 작성하겠습니다

---

왜 스프링 컨테이너를 써야 할까?

위 두 과정을 통해서 스프링 컨테이너를 만드는 것을 알겠는데 왜 스프링 컨테이너를 써야 할까..?

그런 스프링 컨테이너의 특징을 보면 알 수 있다 

특징: 

스프링 컨테이너를 쓰면 스프링 컨테이너가 기본적으로 객체를 싱글톤으로 관리한다. 싱글톤으로 관리하면 이점이 뭘까?

그건 간단하다! 예를 들어 고객이 계속 요청을 할 때마다 객체를 계속 만들면 요청이 올 때마다 계속 계속 객체를 만들어야 하고 

이는 엄청난 메모리 낭비로 이어진다

그래서 이를 해결하고자 객체를 한 개만 생성하고 그 객체를 공유하도록 설정하면 된다 

 

이렇게 스프링 컨테이너는 스프링 빈을 싱글톤으로 관리해 주는 것뿐만 아니라 생명주기까지 모든 걸 관리해 주기 때문에 스프링 빈을 사용해야 한다..!

 

@Configuration

이 어노테이션은 아까 설정 정보 클래스를 만들 때 붙인다고 했다 그리고 빈들을 가져올 때 2가지 방법이 있다고도 했다 

자동 빈 등록은?

     컨테이너가 만들어질 때 같은 클래스가 아닌 다른 클래스를 찾아가서 스프링 컨테이너가 직접 인스턴스를 만들고 싱글톤을 관리한다

수동 빈 등록은?

     @Configuration 클래스 안의 메서드로 등록된 애들이다 근데.. 이러면 문제인 게 같은 클래스 안에서 서로 얽혀있어서 하나의 빈

     을 등록할 때 다른 메서드(@Bean)를 실행시키게 되면  자바 문법상 그냥 new 실행이 되어버려서 싱글톤이 유지가 안될 가능성

     이 생긴다

 

이를 방지하고자 실제로 @Configuration은 이 클래스 안에 있는 @Bean 메서들을 전부 CGLIB 프락시로 감싸서 싱글톤을 유지한다

 

---

ComponentScan

컴포넌트 스캔은 컴포넌트 어노테이션이 붙은 모든 클래스를 스프링 빈으로 등록하는 역할을 한다

이때 등록되는 스프링 빈의 기본 이름은 클래스 명을 사용하되 맨 앞글자만 소문자로 사용한다

 

ComponentScan 탐색 위치와 기본 스캔 대상

아무런 설정을 하지 않으면 어노테이션이 붙은 설정 정보 클래스가 포함된 패키지가 시작 위치가 되어 해당 패키지의 모든 클래스를 다 뒤져서 Component 가 붙은 애들을 다 가져온다

하지만 basePackages를 통해 탐색할 패키지의 시작 위치를 지정하거나 basePackageClass를 통해 지정한 클래스의 패키지를 탐색 시작 위치로 지정할 수 있다

 

ComponentScan의 스캔대상

1. @Component
2. @Controller
3. @Service
4. @Repository
5. @Configuration

ComponentScan의 필터

• includeFilter : 컴포넌트 스캔 대상을 추가로 지정한다
• excludeFilter : 컴포넌트 스캔에서 제외할 대상을 지정한다

includeFilters = @Filter(type = FilterType.ANNOTATION)

 

 

만약 컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까? 

스프링 부트에선 무조건 예외 발생이다!!!