[핵심원리-기본] 컴포넌트 스캔

컴포넌트 스캔과 의존관계 자동 주입 시작하기

• 스프링빈 등록시 @Bean 이나 < bean > 으로 설정정보를 등록했음
• 일일이 등록해야하니까 귀찮고 휴먼에러도 생김
• 스프링은 설정정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능 제공
• 의존 관계 자동 주입하는 @Autowired 도 있음

@Configuration  
@ComponentScan(  
        // 스캔 할 때 제외할 거 넣어줌 -> AppConfig를 등록방지하기 위해  
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION,classes = Configuration.class)  
) // @Comoponet 애노테이션 붙은 거를 다 빈에 등록시켜줌  
public class AutoAppConfig {  

}

컴포넌트 스캔 쓰려면 @ComponentScan 을 설정 정보에 붙여주면 됨
필터를 넣어서 기존에 작성해둔 설정파일들이 빈 컨테이너에 등록되지 않는다

==보통은 필터링 안 함 ,, 공부를 위해서 제거한 거임==

컴포넌트 스캔은 @Component 애노테이션 붙은 클래스를 스캔해서 스프링 빈으로 등록한 거임
@Configuration 이 스캔 대상이 되는 이유는 소스코드에 @Component가 붙어있어서 그럼

*즉 AppConfig 설정파일 없이 @Component로 클래스에 붙여주면 알아서 스프링이 빈에 등록시켜줌 *

@Component  
public class MemoryMemberRepository implements MemberRepository{

@Component  
public class RateDiscountPolicy implements DiscountPolicy{

근데 보면 스프링빈으로 자동으로 등록은 시켜만 주잖아
의존 관계 주입은??

@Component  
public class MemberServiceImpl implements MemberService{  

    private final MemberRepository memberRepository;  

    public MemberServiceImpl(MemberRepository memberRepository) {  
        this.memberRepository = memberRepository;  
    }

여기 @Component로 빈에 등록시켰을 경우 memberRepository 머로 쓸지 정하질 않았는데 이걸 어떻게 쓰냐 이거지...,.

그래서 @Autowired(자동 의존관계 주입) 을 생성자에 붙여주면 된다
그러면 스프링이 알아서 해당 타입에 맞는 객체를 빈 컨테이너에 알아서 찾은 다음 생성자에 쏙 넣어줌

@Component  
public class MemberServiceImpl implements MemberService{  

    private final MemberRepository memberRepository;  

    @Autowired  
    public MemberServiceImpl(MemberRepository memberRepository) {  
        this.memberRepository = memberRepository;  
    }

아마 위에서 @Component 붙인 memoryRepository가 빈컨테이너에 있을테니 그걸 가져와서 자동으로 의존관계 넣어줄 듯

@Autowired == ac.getBean(MemberRepository.class)

@Component  
public class OrderServiceImpl implements  OrderService{  

    // 멤버리파지토리에서 회원 찾기 위해서  
    private final MemberRepository memberRepository ;  
    private final DiscountPolicy discountPolicy;  

    @Autowired  
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {  
        this.memberRepository = memberRepository;  
        this.discountPolicy = discountPolicy;  
    }

위와 같이 수정하면 간편하게 여러 의존관계 , 빈들을 손쉽게 얻을 수 있음

@Test  
void basicScan(){  
    // 설정정보로 AutoAppConfig 넘겨줌  
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class);  

    MemberService memberService = ac.getBean(MemberService.class);  
    Assertions.assertThat(memberService).isInstanceOf(MemberService.class);  
}

출력결과

로그로 어떻게 객체들이 생성되었고 autowired로 객체를 멀 넣었는지 알 수 있음

• @ComponetScan이 붙은 구성파일은 @Component가 붙은 모든 클래스를 파일 내에서 찾은 후에 스프링 빈으로 등록한다
• 빈으로 등록된 기본 이름은 클래스 명을 따르되 앞글자만 소문자로 지정함

• 생성자에 @Autowired를 넣으면 스프링 컨테이너가 자동으로 해당 생성자에 들어갈 파라미터 타입에 맞는 스프링 빈을 컨테이너에서 찾아서 넣어준다
• == getBean(memberRepository.class)

• 넣을 파라미터가 다수라도 알아서 다 찾아서 등록해줌

---

탐색 위치와 기본 스캔 대상

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

• 모든 파일에서 다 찾으면 시간이 오래 걸리니까 탐색할 범위를 지정해 주면 그 범위 내에서 컴포넌트 스캔을 하고 스프링 빈 컨테이너에 등록시킴

• basePackages : 탐색할 패키지 시작 위치 지정 가능하며 복수로 여러 시작 위치 지정 가능

지정하지 않으면 해당 파일의 패키지를 시작위치로 생각하고 스캔을 시작함

이거보면 hello.core부터 시작위치로 생각하고 그 밑으로 쭉 찾는 거임

권장 방법

패키지 위치 지정하지 않고 설정정보 클래스 위치를 프로젝트 최상단에 주는 것이 좋음
스프링부트의 경우 대표 시작 정보인 @SpringBootApplication 이 친구를 시작 루트에 두는 것이 관례 왜냐면 해당 코드 까보면 @ComponentScan이 있음

컴포넌트 스캔 기본 대상

• @Component : 컴포넌트 스캔에서 사용
• @Controller : 스프링 MVC 컨트롤러에서 사용 // 컨트롤러로 인식
• @Service : 스프링 비즈니스 로직에서 사용 // 특정 기능 없음 다만 개발자가 보고 비즈니스 로직 위치 인지 정도
• @Repository : 스프링 데이터 접근 계층에서 사용 // 데이터 접근 계층으로 인식 , 데이터 계층의 예외를 스프링 예외로 변환
• @Configuration : 스프링 설정 정보에서 사용 // 스프링 빈 싱글톤 유지하도록 추가 처리

---

필터

• includeFilters : 컴포넌트 스캔 대상을 추가로 지정
• excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정

@MyExcludeComponent  
public class BeanB {  
}

@MyIncludeComponent  
public class BeanA {  
}

public class ComponentFilterAppConfigTest {  
    @Test  
    void filterScan(){  
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ComponentFilterAppConfig.class);  
        BeanA beanA = ac.getBean("beanA", BeanA.class);  
        // 포함된 빈  
        assertThat(beanA).isNotNull();  
        // 제외된 빈   
assertThrows(  
                NoSuchBeanDefinitionException.class,  
                ()->ac.getBean("beanB", BeanB.class));  
    }  

    @Configuration  
    @ComponentScan(  
            //type = FilterType.ANNOTATION는 기본값이라 생략가능   
includeFilters = @ComponentScan.Filter(classes =  MyIncludeComponent.class),  
            excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes =  MyExcludeComponent.class)  
    )  
    static class ComponentFilterAppConfig{  

    }  
}

보통 @Component면 충분해서 includeFIlters 잘 안 씀
excludeFIlters는 가끔 쓴다

---

중복 등록과 충돌

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

자동 빈 등록 vs 자동 빈 등록

• 컴포넌트 스캔에 의해서 자동으로 빈이 등록이 되고 이 때 이름이 같은 경우 오류가 발생 ConflictingBeanDefinitionException
• 보통 잘 안남

수동 빈 등록 vs 자동 빈 등록

@Configuration  
@ComponentScan(  
        //basePackages = "hello.core.member",  

        // 스캔 할 때 제외할 거 넣어줌 -> AppConfig를 등록방지하기 위해  
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION,classes = Configuration.class)  
) // @Comoponet 애노테이션 붙은 거를 다 빈에 등록시켜줌  
public class AutoAppConfig {  
    @Bean(name = "memoryMemberRepository")  
    public MemberRepository memberRepository() {  
        return new MemoryMemberRepository();  
    }  
}

• 다음과 같이 수동으로 빈등록을 하고 이게 자동 빈등록과 이름이 같은 경우에는 수동 빈이 우선권을 가진다
• 수동빈이 자동빈을 오버라이딩 해버림

로그

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

이걸 개발자가 의도했으면 되겠는데 실제로 이렇지 않다
현업에선 수십개 빈들을 쓸텐데 수동으로 등록하고 어떤 건 자동으로 등록하면 설정이 꼬여서 잡기 어려운 버그가 만들어짐
그래서 빈 등록시 충돌나도록 기본값 변경해버림 !! 하도 이걸로 문제가 많으니까!!

개발에서는 명확하지 않은 건 하면 안된다 협업이니까 애매한 거 만들면 골치아파짐

스프링 부트 에러 로그

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

출처
https://inf.run/wFfL