[Spring] Component Scan And Auto wired Start

📋 목차

---

01. [Spring] 스프링 핵심 원리
02. [Spring] 좋은 객체 지향 설계의 5가지 원칙 (SOLID)
03. [Spring] 객체 지향 설계와 스프링   
04. [Spring] OCP와 DIP 고려하기
05. [Spring] 객체 지향 원리 적용 - 새로운 할인 정책 개발
06. [Spring] AppConfig 리팩터링    
07. [Spring] Ioc, DI Container  
08. [Spring] 스프링 컨테이너 생성  
09. [Spring] 싱글톤 컨테이너  
10. [Spring] Component Scan And Auto wired Start
11. [Spring] 의존관계 주입 방법    
12. [Spring] Bean Life Cycle Call Back
13. [Spring] Bean Scope

 

 

 

📌 컴포넌트 스캔과 의존관계 자동 주입

---

스프링 빈을 등록할 때 자바 코드의 @Bean이나, XML의 <bean> 등을 통해 설정 정보에 직접 등록할 스프링 빈을 나열할 수 있었던 것이에요. 하지만, 이렇게 등록해야 할 스프링 빈이 수십, 수백개라면? 넘나 힘든 것이에요.

개발자는 반복을 싫어하는 것이기 때문인 것도 있어요!

그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공하는 것이에요.

또, 의존관계도 자동으로 주입하는 @Autowired라는 기능도 있답니다!

 

         👉 AutoAppConfig.java 추가

 

컴포넌트 스캔을 사용하려면 먼저 Class 선언에 @ComponentScan을 붙여주면 되는 것이에요.

위와 같이 하면 @Bean을 사용하지 않아도 된답니다!

 

💡참고 :
컴포넌트 스캔을 사용하면 @Configuration이 붙은 설정 정보도 자동으로 등록된다.
excludeFilters는 스프링 빈에 등록하지 않을 내용을 선언하여 제외 시킬 때 사용한다.

 

컴포넌트 스캔은 @Component가 붙은 Class를 찾아서 스프링 빈에 등록해 주는 것이에요.

 

💡참고 :
@Configuration 역시 해당 소스코드 내부를 살펴보면 @Component가 붙어있기 때문에 스프링 빈으로 등록된다.

 

컴포넌트의 스캔 대상이 되도록 하고 싶은 Class에는 @Component를 붙여주면 되는 것이에요.

 

 

         👉 MemoryMemberRepository.java

 

 

 

         👉 RateDiscountPolicy.java

 

 

 

         👉 MemberServiceImpl.java

 

 

  위의 Class에 모두 @Component를 붙여주었고, MemberServiceImpl에는 @Autowired를 추가해 주었습니다.

 

@Bean을 사용하면 설정 정보를 수동으로 직접 작성할 수 있고, 이를 통해 의존관계도 직접 명시할 수 있는 것이에요.

하지만, 위의 방법대로 하게 된다면 설정 정보 자체가 없기 때문에 의존관계 주입도 이 클래스 안에서 해결해야 하는 것이에요.

그러기 위해 사용하는 것이 @Autowired이랍니다!

 

         👉 OrderServiceImpl.java

 

 

@Autowired를 사용하면 생성자에서 여러 의존관계도 한번에 주입 받을 수 있는 것이에요!

 

 

         👉 AutoAppConfigTest.java

 

 

@Component를 사용한다고 해도 AnnotaionConfigApplicationContext를 사용하는 것은 @Bean을 사용하는 것과 동일한 것이에요. 이를 통해 설정 정보로 AutoAppConfig 클래스를 넘겨줄 수 있답니다!

 

 

📖 Test 결과

 

 

위와 같이 아주 잘 동작하는 것을 확인할 수 있답니다!

 

23:17:08.996 [Test worker] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'org.springframework.context.annotation.internalConfigurationAnnotationProcessor'
23:17:09.125 [Test worker] DEBUG org.springframework.context.annotation.ClassPathBeanDefinitionScanner - Identified candidate component class: file [D:\01.Synology_Sync\Person\97.source_code\00.study\00.Inflearn\스프링 핵심 원리 - 기본편\build\classes\java\main\hello\core\discount\RateDiscountPolicy.class]
23:17:09.129 [Test worker] DEBUG org.springframework.context.annotation.ClassPathBeanDefinitionScanner - Identified candidate component class: file [D:\01.Synology_Sync\Person\97.source_code\00.study\00.Inflearn\스프링 핵심 원리 - 기본편\build\classes\java\main\hello\core\member\MemberServiceImpl.class]
23:17:09.130 [Test worker] DEBUG org.springframework.context.annotation.ClassPathBeanDefinitionScanner - Identified candidate component class: file [D:\01.Synology_Sync\Person\97.source_code\00.study\00.Inflearn\스프링 핵심 원리 - 기본편\build\classes\java\main\hello\core\member\MemoryMemberRepository.class]
23:17:09.132 [Test worker] DEBUG org.springframework.context.annotation.ClassPathBeanDefinitionScanner - Identified candidate component class: file [D:\01.Synology_Sync\Person\97.source_code\00.study\00.Inflearn\스프링 핵심 원리 - 기본편\build\classes\java\main\hello\core\orderImsi\OrderServiceImpl.class]

 

그렇다면 컴포넌트 스캔과 자동 의존 관계 주입이 어떻게 동작하는 것일까요?

 

 

         👉 @ComponentScan

 

 

@ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록하는 것이에요.

이 때, 스프링 빈의 기본 이름은 클래스명을 사용하되, 맨 앞 글자만 소문자로 바꿔서 등록하는 것이에요.

• 빈 이름 기본 전략 : MemberServiceImpl Class => memberServiceImpl
• 빈 이름 직접 지정 : 만약 스프링 빈의 이름을 직접 지정하고 싶을 시 아래와 같이 사용

  • @Component("[Spring Bean Name]")

 

 

 

         👉 @Autowired 의존 관계 자동 주입

 

 

생성자에 @Autowired를 지정하게 되면 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입하는 것이에요.

이 때, 기본 조회 전략은 자료형 타입(객체형)이 같은 빈을 찾아서 주입하는 것이에요. 

getBean(MemberRepository.class)

위의 코드와 비슷하다고 보면 될 것이에요!

 

반응형

 

생성자에 매개 변수(파라미터)가 많아도 다 찾아서 자동으로 주입하는 것이에요.

 

 

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

         👉 탐색할 패키지의 시작 위치 지정

모든 자바 클래스를 다 컴포넌트 스캔을 하게 되면 어떻게 될까요? 아마 엄청난 시간이 걸리게 될 것이에요. 그래서 꼭 필요한 위치부터 탐색하도록 설정 해 줄 수 있는 것이에요.

 

@ComponentScan(
	basePackages = "hello.core",
}

 

위의 코드에서 basePackages는 탐색할 패키지의 시작 위치를 지정하는 것이에요. 이 패키지를 포함해서 하위 패키지를 모두 탐색하는데, 그 외에 내용들은 탐색하지 않는 것이에요.

만약 basePackages = {"hello.core", "hello.service"}와 같이 해 주었다면 core와 service하위 내용들만 모두 탐색할 것이에요. 만약 이것을 지정하지 않게 되면 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 되는 것이에요.

 

권장 사항

패키지 위치를 위와 같이 따로 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두게 된다면 우리 프로젝트 내에 내용들만 스캔을 할 것이기 때문에 권장한다.

 

만약 아래와 같이 프로젝트가 구성되어 있다면?

 

• com.hello
• com.hello.services
• com.hello.repository

 

com.hello => Project Start Root Package(Directory) 이 곳에 AppConfig등과 같은 Main Configuration 정보를 두고, @ComponentScan을 붙이고, basePackges를 생략

 

위의 권장사항대로 하게 되면 com.hello를 포함한 하위 모든 내용은 자동으로 컴포넌트 스캔 대상이 되는 것이에요. 그리고, 프로젝트 메인 설정 정보는 프로젝트를 대표하는 정보이기 때문에 최상단 위치(루트)에 두는 것이 좋답니다!

참고로 스프링 부트 사용 시 스프링 부트의 대표 시작 정보인 @SpringBootApplication을 이 프로젝트 시작 루트 위치에 두는 것이 관례라고 하네요! 이 어노테이션 안에는 @ComponentScan이 들어있답니다!

 

 

         👉 컴포넌트 스캔 기본 대상

컴포넌트 스캔은 @Component와 함께 아래 내용도 추가로 포함 되는 것이에요.

1. @Component : 컴포넌트 스캔 시 스캔 당할 Class 선언
2. @Controller : 스프링 MVC 컨트롤러에서 사용
3. @Service : 스프링 비즈니스 로직에서 사용
4. @Repository : 스프링 데이터 접근 계층에서 사용
5. @Configuration : 스프링 설정 정보에서 사용

 

위의 클래스의 소스 코드를 살펴 보면 모두 @Component를 포함하는 것을 알 수 있는 것이에요.

@Component public @interface Controller {
}

@Component public @interface Service {
}

@Component public @interface Configuration {
}

 

 

💡참고 :
어노테이션 간에는 상속 관계는 존재하지 않은데, 특정 어노테이션을 들고 있는 것을 인식할 수 있는 것은 자바 언어의 기능이 아니고, 스프링이 지원하는 기능

 

컴포넌트 스캔의 용도 뿐 아니라 다음 어노테이션이 있으면 스프링은 부가 기능을 수행하는 것이에요.

 

1. @Controller : 스프링 MVC Controller로 인식
2. @Repository : 스프링 Data Access Layer로 인식하고, Data Layer의 Exception을 스프링 Exception으로 변환
3. @Configuration : 스프링 Configuration Infomation을 인식하고, 스프링 빈이 싱글톤을 유지하도록 처리
4. @Service : 특별한 기능은 없으나, 개발자들이 핵심 비즈니스 로직이 여기에 있다는 것을 알게 하기 위해 사용

 

 

💡참고 :
useDefaultFilters Option은 기본적으로 켜져 있는데, 이것을 끄게 되면 기본 스캔 대상들 제외
(단순 참고 사항)

 

 

 

📌 Filter

---

 

1. includeFilters : 컴포넌트 스캔 대상 추가 지정
2. excludeFilters : 컴포넌트 스캔 대상 제외 지정

 

      👉 컴포넌트 스캔 대상 추가 어노테이션

 

 

      👉 컴포넌트 스캔 대상 제외 어노테이션

 

 

 

      👉 컴포넌트 스캔 대상 추가할 클래스(@MyIncludeComponent 적용)

 

 

 

      👉 컴포넌트 스캔 대상 제외할 클래스(@MyexcludeComponent 적용)

 

 

 

 

      👉 설정 정보와 전체 테스트 코드

 

 

위에 includeFilters에 MyIncludeComponent 어노테이션을 추가해서 BeanA가 등록되었고, excludeFilters에 MyExludeComponent 어노테이션을 추가해서 BeanB는 등록되지 않게 한 것이에요.

 

 

    📍 FilterType Option

FilterType에는 5가지 Option이 있는 것이에요.

1. ANNOTION : Default, 어노테이션을 인식해서 동작
   • 예 :) org.example.SomeAnntaion
2. ASSIGNABLE_TYPE : 지정한 Type과 자식 Type을 인식해서 동작
   • 예 :) org.example.SomeClass
3. ASPECTJ : AspectJ Pattern 사용
   • 예 :) org.example..*Service+
4. REGEX : 정규 표현식 사용
   • 예 :) org\.example\.Default.*
5. CUSTOM : TypeFilter 라는 Interface를 구현해서 처리
   • 예 :) org.example.MyTypeFilter

 

 

      👉 BeanA를 빼고 싶을 때의 예시 코드

@ComponentScan(
 includeFilters = { @Filter(type = FilterType.ANNOTATION, classes = MyIncludeComponent.class),
 },
 
 excludeFilters = { @Filter(type = FilterType.ANNOTATION, classes = MyExcludeComponent.class),
 @Filter(type = FilterType.ASSIGNABLE_TYPE, classes = BeanA.class)}
)

 

💡참고 :
@Component를 사용해도 충분하기 때문에 includeFilters를 사용할 일은 거의 없다.
excludeFilters는 여러 이유로 간혹 사용할 수도 있으나, 많지는 않다.
최근 스프링 부트는 컴포넌트 스캔을 기본으로 제공하는데, 스프링 기본 설정에 최대한 맞추어 사용하는 것이 좋다.

 

 

📌 중복 등록과 충돌

---

컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까요? 다음 두가지 상황이 발생할 수 있는 것이에요.

1. 자동 빈 등록 VS 자동 빈 등록
2. 수동 빈 등록 VS 자동 빈 등록

 

 

    📍  자동 빈 등록 VS 자동 빈 등록

컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 Exception을 발생 시키는 것이에요.

ConflictiongBeanDefinitionException 발생!

 

 

    📍  수동 빈 등록 VS 자동 빈 등록

수동 빈 등록과 자동 빈 등록에서 빈 이름이 충돌되면 어떻게 될까요?

 

@Component
public class MemoryMemberRepository implements MemberRepository {}

 

@Configuration
@ComponentScan( excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class))
public class AutoAppConfig {
 
 @Bean(name = "memoryMemberRepository")
 public MemberRepository memberRepository() {
 return new MemoryMemberRepository();
 }
}

 

이렇게 될 경우에는 수동으로 등록한 빈이 우선권을 가지게 되는 것이고, 수동 빈이 자동 빈을 재정의(Overriding)하는 것이에요.

 

Overriding bean definition for bean 'memoryMemberRepository' with a different 
definition: replacing

 

수동 빈 등록시 위와 같은 Log가 남게 된답니다!

 

👨‍🏫 김영한 강사님의 조언

개발자가 의도적으로 이런 결과를 기대했다면 자동 보다는 수동이 우선권을 가지면 좋습니다.
하지만, 현실은 개발자가 의도적으로 설정해서 이런 결과가 만들어지기 보다 여러 설정들이 꼬여 결과가 만들어지게 됩니다.
그렇게  되면 정말 잡기 어려운 Bug가 만들어지게 되고, 이러한 잡기 어려운 Bug는 항상 애매합니다.
그래서  스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌이 나면 Exception이 터지도록 기본값을 설정해 두었습니다.

 

Consider renaming one of the beans or enabling overriding by setting 
spring.main.allow-bean-definition-overriding=true

위의 Exception은 수동 빈과 자동 빈 등록 시 충돌이 나면 스프링 부트에서 터트리는 내용인 것이에요.

 

spring.main.allow-bean-definition-overriding=true

위 내용을 application.properties에서 아래와 같이 변경하면 Exception이 터지지 않는답니다!

spring.main.allow-bean-definition-overriding=false

 

 

 

 

---

 

주니하랑의 글이 마음에 드셨나요? 구독과 공감! 그리고, 댓글 그리고 방명록은 주니하랑에게 많은 힘이 됩니다.