Spring component scan

강정우·2023년 11월 3일

Spring

Spring-boot

목록 보기

12/73

컴포넌트 스캔

지금까지 우리는 xml에서는 <bean\>태그를 작성하고 자바코드에서는 @Bean 어노테이션으로 설정정보에 직접 스프링빈을 등록할 정보를 나열했었다.
하지만 우리가 등록해야하는 빈이 수백개가 되면 어떻게 될까? => 설정정보가 굉장히 커지고 또 실수로 몇개를 빼먹을 수 있다.
스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다.
+ 또한 의존관계 주입도 자동으로 해주는 autowired라는 기능도 제공한다.

컴포넌트 스캔

컴포넌트 스캔은 @Component 가 붙은 클래스들을 찾아가지고 다 자동으로 스프링 빈으로 등록을 해준다.
참고로 아래와 같이 excludeFilter에 지정해두면 @ComponentScan으로 자동으로 스프링빈에 등록할 때 빼주는 것이다.

@Configuration
@ComponentScan(
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
)
public class AutoAppConfig {

}

근데 지금 위 코드를 왜 하냐면 우리가 앞서 등록했던 수동 AppConfig에 @Configuration 어노테이션이 붙어있었는데 이는 보면 @Component를 상속받고있기 때문에 수동 AppConfig도 scan해서 충돌이 나니까 잠깐 빼둔 것이다.
(즉, 실무에서는 잘 쓰진 않고 여기서만 테스트코드가 깨지는걸 방지하기위해서...)
자 그럼 이제 AutoAppConfig는 위처럼 작성했고 클라이언트 단에서는 아래와 같이 수동 AppConfig에 작성되어있는 DI를 가져와서 아래 코드에 집어넣었다.

// @Component
public class MemberServiceImpl implements MemberService {
	private final MemberRepository memberRepository;
    
    // @Autowired
    public MemberServiceImple(MemberRepository memberRepository){
    	this.memberRepository = memberRepository;
    }
    
    ...
}

그런데 위 코드에서 주석만 해제하면 @Component가 자동으로 스프링 빈으로 등록시킨다. 그러면 의존성 주입은 어떻게 하나? => 왜냐하면 그 전에 수동 AppConfig는 의존성 주입으로 클라이언트(~~Impl) @Bean으로 등록을 했기 때문이다.
그런데 지금 자동 AppConfig는 위에 2개의 어노테이션을 제외하고 아무것도 작성되어있지 않다...
그리고 ~~Impl 자체가 지금 @Component 어노테이션으로 빈으로 자동으로 등록되어버렸다. 그럼 다시 의존성은 어떻게 주입할 것인가? => @Autowired : 즉, 이름 그대로 생성자에 어노테이션을 붙여주면 타입(인터페이스 명)을 보고 자동으로 등록을 해준다.

즉, 컴포넌트 스캔을 쓰기위해서는 컴포넌트 어노태이션을 달아야한다. => 컴포넌트 어노태이션은 자동으로 빈으로 등록이 된다. => 컴포넌트에 의존성 주입을 위한 코드가 없으니 (컴포넌트 스캔은 스프링이 알아서 하니까 DI 코드가 없다.) => @autowired 어노테이션이 자동으로 의존성 주입을 해준다. 마치 ac.getBean(MemberRepository.class) 인것 처럼..

수동 AppConfig에서는 @Bean으로 직접 설정 정보를 작성했고, 의존관계도 직접 명시했다. 이제는 이런 설정 정보 자체가 없기 때문에, 의존관계 주입 도 이 클래스 안에서 해결해야한다.

컴포넌트 스캔 동작원리

@ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다. 이때 당연히 싱글톤으로 등록한다.
이때 스프링 빈의 기본 이름은 클래스 명을 사용하되 맨 앞글자만 소문자로 사용한다.
* 빈 이름 기본 전략 : MemberServiceImpl -> memberServiceImpl
- 빈 이름 직접 지정 : 만약 스프링 빈의 이름을 직접 지정하고 싶으면 @Component("memberService2") 라고 작성하면 된다.

@Autowired(의존관계 자동주입) 동작원리

생정자에 @Autowired를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.
이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다.
* getBean(MemberRepository.class)와 동일하다고 이해하면 된다.
- 물론 완전 동일한 건 아니고 더 많이 기능이 포함되어있다.
- 물론 같은 타입이 여러개 있을 수 있다. 그럼 어떻게 해결할까? ->

컴포넌트 스캔 탐색위치

탐색할 패키지의 시작 위치를 지정할 수 있다. 왜? -> 모든 자바 클래스(밑에있는 라이브러리들 모두 포함)를 다 컴포넌트 스캔하면 굉장히 오래걸리기 때문에 꼭 필요한 위치부터 탐색하도록 시작 위치를 지정할 수 있다.

package hello.core; // <= basePackageClasses가 동작하는 패키지임.

import ...

@ComponentScan{
		basePackages = "{본인.패키지, 본인.패키지.더딥한패키지}"
        basePackageClasses = AutoAppConfig.class
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class
}

만약 위 코드에서 더딥한패키지를 붙였다면 해당 패키지만 컴포넌트 스캔 대상이 된다.
그리고 위 처럼 {} 를 붙여 여러 시작 위치를 지정할 수도 있다.
또한 basePackageClasses를 지정할 수 있는데 이는 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다.
참고로 basePackage를 지정하지 않으면 @ComponentScan 을 붙인 클래스가 속한 패키지를 전부 뒤진다. 그니까 AutoAppConfig 클래스에 basePackageClasses = AutoAppConfig.class 랑 똑같음

Convention Code

패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것이다. 무슨말이냐?

com.hello
com.hello.service
com.hello.repository

이런 패키지 구조가 있다고 한다면 최상단 즉, com.hello에 설정정보(AutoAppConfig같은)파일을 위치해둔다는 것이다.

그런데 참고로 spring boot로 넘어가면 @SpringBootApplication 이라는 설정정보가 있는데 이 파일도 통상 root 폴더(패키지.이름)에 위치하고 기본적으로 @ComponentScan을 상속받고 있어서 @ComponentScan를 굳이 또 다른데에 등록할 필요가 없다.

컴포넌트 스캔 기본 스캔 대상

@Component : 컴포넌트 스캔에서 사용
@Controller : 스프링 MVC 컨트롤러에서 사용
@Service : 스프링 비즈니스 로직에서 사용
@Repository : 스프링 데이터 접근 계층에서 사용 (JPA, JDBC)
@Configuration : 스프링 설정 정보에서 사용

그런데 알아두어야 할 것은 -> 어노테이션은 정확하게는 상속관계라는게 없다. 그래서 어노테이션이 특정 어노테이션을 들고 있는 것을 인식할 수 있는 것은 자바가 아니라 스프링 기능이다.
어노테이션의 부가기능은 메타정보라서 그걸 보고 내가 뭘 더해야지를 인식할 수도 있다.
컴포넌트 스캔의 용도 뿐만 아니라 다음 어노테이션이 있으면 스프링은 부가 기능을 수행한다.
* @Controller : 스프링 MVC 컨트롤러로 인식
- @Repository : 스프링 데이터 접근 계층으로 인식하고, "데이터 계층의 예외"를 "스프링 예외"로 변환해줌.
- @Configuartion : 앞서 보았듯 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다.
- @Service : 사실 @Service는 특별한 처리를 하지 않는다. 이는 사용자들을 위한 표식에 가깝다. 그래서 보통 여기에 @Transaction 같은거 같이 걸어서 트랜잭션도 시작한다.
userDefaultfilters 옵션은 기본적으로 켜져있는데, 이 옵션을 끄면 기본 스캔 대상들이 제외된다. (중요 X)

컴포넌트 스캔 필터

우선 스캔 플터를 만들기 전에 앞서 custome annotaion을 작성해보자. 생성은 똑같이 자바 파일 만드는 데 가면 최하단에 annotation이라고 명시되어있다.

Target에는 굉장히 다양한 속성값이 있는데 여기서는 Type을 지정해주겠다. 그러면 클래스 레벨에 붙는 것이다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyIncludeComponent {

}

그래서 일단 커스텀 어노테이션을 작성해주고

@MyIncludeComponent
public class BeanA {
}

이 어노테이션을 등록하여 컴포넌트로 등록해준다.

public class ComponentFilterAppConfigTest {
    @Test
    void filterScan() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(ComponentFilterAppConfig.class);
        BeanA beanA = ac.getBean("beanA", BeanA.class);
        assertThat(beanA).isNotNull();
        
        org.junit.jupiter.api.Assertions.assertThrows(NoSuchBeanDefinitionException.class, () -> ac.getBean("beanB", BeanB.class));
        // 위 코드가 너무 길면 커서를 assertThrows에 두고 alt + enter로 static import 하면 됨.
    }

    @Configuration
    @ComponentScan(
            includeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyIncludeComponent.class),
            excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyExcludeComponent.class)
    )
    static class ComponentFilterAppConfig{
    }
}

그리고 이를 있는지 확인하기위해서 filter 메서드를 돌리면 테스트에 성공한다.
그리고 만약 Exclude 어노테이션을 등록한 BeanB를 찾으려 한다면 당연하게도 테스트에 실패할 것이다.

컴포넌트 스캔 필터 옵션

ANNOTATION : 기본값, 어노테이션을 인식해서 동작한다.
- org.example.SomeAnnotaion
- type = FilterType.ANNOTATION 이 부분이기도 함 (default임)
ASSIGNABLE_TYPE : 지정한 타입과 자식 타입을 인식해서 동작한다.
- org.example.SomeClass
ASPECTJ : AspectJ 패턴 사용
- org.example..*Service+
REGEX : 정규표현식
- org.example.Default.*
CUSTOM : TypeFilter라는 인터페이스를 구현해서 처리
- org.example.MyTypeFilter

중복 등록과 충돌

자 앞서 언급 했던 컴포넌트 스캔을 진행할 때 같은 빈 이름을 등록하면 어떻게 될까? 우선 2가지의 경우의 수가 있다.

자동 빈 등록 vs 자동 빈 등록
수동 빈 등록 vs 자동 빈 등록

자동 빈 등록 vs 자동 빈 등록

컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다.
* ConflicBeanDefinitionException 예외 발생

수동 빈 등록 vs 자동 빈 등록

이땐 수동 빈 등록이 더 우선권을 가져간다. 그래서 overriding bean definition 이 일어나서 자동 빈 등록을 수동 빈 등록이 덮어씌워버린다.
그런데 이게 개발자가 의도하면 괜찮은데 수많은 개발자가 협업을 하다보면 이를 의도한 것이 아닌 실수로 덮어씌워버릴 수 있다. 이는 설정들이 꼬이는 지름길이고 버그도 잡기가 매우 힘들어진다.
그래서 스프링말고 스프링 부트에서는 수동빈등록과 자동빈등록이 충돌나면 오류를 내보내도록 바꿨다.
그래서 부트 프로젝트에서 물론 그럴일은 없겠지만 이악물고 overriding을 쓰겠다. 이 옵션을 true로 바꾸고 싶다! 하면 application.properties에 넣어주면 된다.