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

해당 글은 김영한님의 인프런 강의를 공부하고 정리한 내용입니다.

 

# 컴포넌트 스캔?

앞에서 스프링 빈을 등록할 때 Java 어노테이션 코드 (@Bean)이나 XML <bean>등을 통해 설정정보에 직접 등록한 스프링 빈을 지정해주었다. 하지만 이 작업은 프로젝트가 커지면 일일이 하나하나 적어주기도 번거럽고, 수정할 때 누락되는 경우도 자주 발생한다.

 

그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록해주는 컴포넌트 스캔이라는 기능을 제공한다. 또 드디어 맨날 보던 @Autowired 라는 의존관계를 자동으로 주입해주는 기능도 제공한다.

 

# 컴포넌트 스캔을 사용해보자

간단하다. @ComponentScan 어노테이션을 사용하여 사용할 수 있다. 참고로 컴포넌트 스캔을 하게되면 @Configuration이 붙은 설정 정보도 자동으로 등록된다. @Configuration 내부에 @Componet가 선언되어 있기 때문이다. 그래서 예제에서 적은 설정정보를 컴포넌트 스캔에 제외하기 위해 excludeFilter를 사용하여 아래와 같이 적어주었다. (* 보통은 굳이 설정정보를 excludeFilter로 사용하지 않고, 그냥 컴포넌트 스캔을 사용한다.)

@Configuration
@ComponentScan(excludeFilters = @Filter(type = FilterType.ANNOTATION,
        classes = Configuration.class))
public class AutoAppConfig {
    // 생략한게 아니다. 등록한 클래스가 하나도 없다.
}

컴포넌트 스캔을 등록했다면, 아래와 같이 각각의 클래스에 @Component 어노테이션을 붙여주자.

@Component
public class MemoryMemberRepository implements MemberRepository {
    public static Map<Long, Member> store = new HashMap<>();
 
    @Override
    public void save(Member member) {
        store.put(member.getId(), member);
    }
 
    @Override
    public Member findById(Long memberId) {
        return store.get(memberId);
    }
}

@Component
public class RateDiscountPolicy implements DiscountPolicy {
    private int discountPercent = 10;
 
    @Override
    public int discount(Member member, int price) {
        if (member.getGrade() == Grade.VIP) {
            return price * discountPercent / 100;
        }
        return 0;
    }
}

 

위에도 언급했다싶이 @Autowired를 사용하면 의존관계를 자동으로 주입 할 수 있다. 즉 앞에서 AppConfig에서 인터페이스에 구현체를 넣어주는 과정을 컴포넌트를 스캔하여 자동으로 처리 해준다. (다른 기능도 있는데, 이는 나중에 추가로 설명하겠다.)

@Component
public class MemberServiceImpl implements MemberService {
    private final MemberRepository memberRepository;
 
    @Autowired
    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    
    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }
 
    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
 
}

 

컴포넌트 스캔이 정말 제대로 동작하는지 테스트코드를 통해 알아보자. 

public class AutoAppConfigTest {
    @Test
    void basicScan() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class);
        
        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberService.class);
    }
}

 

---

# 컴포넌트 스캔의 동작과정

@ComponentScan을 설정하면, @Component가 붙은 모든 클래스를 자동으로 스프링 빈으로 등록한다. 이전처럼 AppConfig에서 의존관계 주입 메서드에 하나하나 @Bean을 붙여주지 않아도 된다. (@Configuration 처럼 해당 태그 내부에 @Component가 선언되어 있는 클래스도 생성 대상이 됨을 유의하자.)

 

그리고 생성자에 @Autowired를 지정하면, 아래와 같이 AppConfig의 @Bean 메서드에서 의존관계를 하나하나 주입해주던 것을 대신 해준다.

//* @ComponentScan 으로 빈 등록, @Autowired로 의존관계를 주입한 코드 *
@Configuration
@ComponentScan(excludeFilters = @Filter(type = FilterType.ANNOTATION,
        classes = Configuration.class))
public class AutoAppConfig {
    // 생략한게 아니다. 등록해야하는 클래스가 하나도 없다.
}

//* 기존의 코드 *
@Configuration // 구현체를 싱글톤 객체로 유지시켜주는 태그.
public class AppConfig {
    @Bean // memoryRepository 의존관계 주입
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    
    @Bean // memberService에 의존관계 주입.
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
 
    @Bean // OrderService에 의존관계 주입.
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
     ... 생략 ...
}

@Autowired의 원리는 스프링 컨테이너가 [등록된 스프링 빈]중에서 타입이 같은 빈을 찾아 의존관계를 주입한다. 기본 동작은 같은 타입의 빈을 조회하는 getBean(MemberRepositoryt.class) 메서드를 사용하여 memoryMemberRepository를 찾아 등록해주는 방식이라고 생각하면 된다. 

 

 

---

# 컴포넌트 탐색 위치지정

@ComponentScan는 프로젝트 내의 모든 자바 클래스, 라이브러리를 뒤져서 @Component를 찾아 스캔한다. 이 과정은 시간이 오래걸리게 되는데, basekPackages 옵션을 이용하여 탐색할 위치를 지정해줄 수 있다.

• basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함한 하위 패키지를 모두 탐색한다.
• basePackages = {"hello.core", "hello.service"} 처럼 여러 개를 지정해줄 수 있다. 동작은 동일하다.
• basePackageClasses : 지정한 클래스가 속한 패키지를 탐색 시작위치로 지정한다.
  (=> 지정하지 않으면 @ComponentScan이 붙은 설정 클래스가 시작위치가 된다.)

스프링에서 권장하는 방법은, 설정 클래스(AppConfig)를 프로젝트 시작 루트에 두고 지정하지 않고 사용하는 것이다. ( 스프링 부트를 사용하면 @SpringBootApplication을 앱 시작에 두는게 일반적인데, 해당 태그 안에 @ComponentScan이 포함되어 있기 때문이기도 하다.)

@ComponentScan(
     basePackages = "hello.core"
)

---

# 컴포넌트 스캔 기본대상

참고로 @ComponentScan은 @Component 뿐만 아니라 아래의 태그들도 자동 스캔대상에 추가한다. (이는 해당 태그 안에 @Component 태그를 포함하고 있기 때문이다.)

• @Component : 컴포넌트 스캔에서 사용
• @Configuration : 스프링 설정 정보에서 사용
• @Controller : 스프링 MVC 컨트롤러에서 사용 + 스프링 MVC 컨트롤러로 인식함.
• @Repository : 스프링 데이터 접근 계층에서 사용 + DB에서 터진 예외를 스프링 예외로 추상화해서 변환해줌.
• @Service : 스프링 비즈니스 로직에서 사용 + 특별한 처리는 없음. 그냥 비즈니스 로직임을 나타내기 위함.

* 한번 언급하고 넘어가자면, 어노테이션은 'Java'의 기능이지만 이를 상속하듯이 사용하는 건 '스프링 프레임워크'에서 지원하는 기능이다. 즉 커스텀 어노테이션 태그를 만들 수도 있고, 스프링의 옵션 (userDefaultFilters)을 바꿔 기본 스캔대상을 모두 제외할 수도 있다.

 

---

# 스캔대상 필터

앞에서도 언급했지만, @ComponentScan에 아래 옵션을 통해 스캔대상을 제외/추가지정 해줄 수 있다. 필터의 정확한 사용방법은 스프링 어노테이션을 알아야 하므로, 일단 아래와 같이 가능하다는거만 알고 넘어가자.

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

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

@Filter의 type 기본값은 ANNOTATION으로 해당 어노테이션을 인식해서 동작하도록 되어있다. 잘 사용할 일은 없지만  특정 클래스나 정규표현식을 필터조건으로 넣어줄 수도 있다. 예를 들어 BeanA라는 클래스를 제외하고싶으면 다음과 같이 작성하면 된다. @Filter(type = FilterType.ASSIGNABLE_TYPE, classes = BeanA.class)

import java.lang.annotation.*;
 
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyIncludeComponent {
	// 컴포넌트 스캔에 추가하고 싶은 어노테이션 정의
}
 
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent {
	// 컴포넌트 스캔에 제외하고 싶은 어노테이션 정의
}
 
@MyIncludeComponent
public class BeanA {
	// 컴포넌트 스캔에 추가하고 싶은 클래스
}
 
@MyExcludeComponent
public class BeanB {
	// 컴포넌트 스캔에 제외하고 싶은 클래스
}

아래와 같은 테스트 코드를 통해 해당 컴포넌트가 제대로 등록/제외 되었는지도 확인해보자.

public class ComponentFilerAppConfigTest {
    @Test
    void filterScan() {
        ApplicationContext ac = new
                AnnotationConfigApplicationContext(ComponentFilterAppConfig.class);
        BeanA beanA = ac.getBean("beanA", BeanA.class);
        assertThat(beanA).isNotNull();
        Assertions.assertThrows(
                NoSuchBeanDefinitionException.class,
                () -> ac.getBean("beanB", BeanB.class));
    }
    
    // 테스트용 AppConfig 이름 -> ComponentFilterAppConfig
    @Configuration
    @ComponentScan(
            includeFilters = @Filter(type = FilterType.ANNOTATION, classes =
                    MyIncludeComponent.class),
            excludeFilters = @Filter(type = FilterType.ANNOTATION, classes =
                    MyExcludeComponent.class)
    )
    static class ComponentFilterAppConfig {}
}

 

---

# 컴포넌트 중복 등록과 충돌

빈 이름을 같게 등록하게되면 덮어씌워지거나 오류가 발생할 수 있다고 앞에서 배웠다. 컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까? 아래 두 가지 상황을 생각해보자.

@자동 빈 등록 vs 자동 빈 등록

이는 간단하다. 컴포넌트 스캔에 의해 등록되다가 이름이 같은 빈을 발견한 경우 스프링은 예외(ConflictingBeanDefinitionException)를 발생시킨다. 

 

 

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

그렇다면 내가 직접한 빈과 자동으로 만들어진 빈 이름이 겹친다면? 이 경우 수동으로 등록한 빈이 자동으로 등록한 빈을 오버라이딩 해버린다.

// 자동, 컴포넌트 스캔
@Component
public class MemoryMemberRepository implements MemberRepository {}

// 수동으로 @Bean 등록 및 의존관계 생성
@Configuration
@ComponentScan(
        excludeFilters = @Filter(type = FilterType.ANNOTATION, classes =
                Configuration.class)
)
public class AutoAppConfig {
    @Bean(name = "memoryMemberRepository")
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

실제 스프링 콘솔창에서 다음과 같이 오버라이딩 되었음을 메시지로 알려준다. 의도적으로 이렇게 했다면 다행이지만, 보통의 경우 설정이 꼬여서 덮어씌워지게 되는데 이는 버그라고 하기에 애매한 상황이라 정말 잡기 어려운 장애를 만들어 낼 수 있다. (그래서 최근 스프링 부트 CoreApplication에서는 수동 vs 자동 충돌이나면 오류가 나도록 기본값을 바꾸었다.)

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

 

---

# 의존관계 자동주입 (@Autowired)

의존관계를 주입하는 방법은 총 4가지가 있다.

• 생성자 주입
• 수정자 주입(생성자 대신 setter사용)
• 필드 주입
• 일반 메서드 주입

 

@ 생성자 주입

특별한 이유가 없다면, 생성자로 주입하는 것이 좋다.

앞에서 계속 사용했던 방법이다. 생성자를 사용하면 좋은점이 호출 시점에 딱 1번만 호출되어 불변한 객체 의존관계를 만들 수도 있다. 또 필드에 final 키워드를 적어 혹시나 초기화(설정)되지 않는 오류를 컴파일 시점에 잡을 수 있다.

* 생성자가 딱 1개만 있다면, @Autowired를 생략해도 동일하게 동작한다. (물론 스프링 빈에만 해당되는 내용이다.)

* 만약 자동으로 주입할 스프링 빈이 등록되지 않았다면 오류를 발생시킨다 -> @Autowired(required=true) 옵션

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
 
    // 생성자를 통해서 의존관계를 주입한다.
    // Autowired 키워드는 현재 등록된 빈들의 타입을 비교해서, 필요한 구현체를 연결시킨다.
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

 

---

@ 수정자 주입(Setter)

구현체가 [선택, 변경] 가능성이 있는 경우 생성자 대신 수정자(Setter)를 사용하여 주입한다. 다만 특별한 경우가 아니라면 구현체의 불변성을 지키기 위해 생성자로 주입하는 것을 권장한다. 

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
 
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
 
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
}

 

---

@ 필드 주입( @Autowired Object a; )

이름 그대로 필드에 바로 주입하는 방법인데, 실제 앱에서는 사용하지 않는 것을 추천한다. 코드는 짧아지지만, 외부에서 변경이 불가능해서 나중에 테스트하기 어렵다. 필드 주입을 사용하는 경우는 실제 코드와 상관없는 테스트 코드를 간단히 작성할 때, 혹은 스프링 설정을 목적으로 하는 @Configuration 같은 특별한 용도로만 사용된다.

@Component
public class OrderServiceImpl implements OrderService {
    @Autowired
    private MemberRepository memberRepository;
    
    @Autowired private DiscountPolicy discountPolicy;
}

// 테스트 코드를 작성할 때 많이 사용한다. 말 그대로 테스트용 코드니까
@SpringBootTest
class CoreApplicationTests {
    @Autowired OrderService orderService;
    
    @Test
    void contextLoads() {
        ...
    }
}

 

---

@ 일반 메서드 주입

생성자, setter, 필드 이외에도 아무 메서드에도 Autowried를 사용해서 자동으로 의존관계 주입을 받을 수 있긴하다. 하지만 보통 사용할 일이 없는 기능이다.

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

 

* 한번 더 말하지만, 의존관계 주입이라함은 스프링 컨테이너에 등록되어있는 @Bean들의 의존관계를 말하는 것이다. 스프링 빈 객체로 등록되지 않은 자바 클래스(Member)에 @Autowired 코드를 적어봐야 자동으로 주입되지 않는다.

 

---

# 옵션처리, 스프링 빈이 없어도 동작해야 할 때

자동으로 주입할 스프링 빈이 등록되지 않았다면 오류를 발생시킨다 -> @Autowired(required=true) 옵션

스프링 컨테이너에 자동 주입할 빈이 없을 때, 옵션으로 다르게 처리하는 방법은 아래와 같다. 참고로 @Nullable과 Optional은 Autowired을 사용할 때 뿐 아니라 특정 필드에만 따로 사용할 수도 있다.

• @Autowired(required=false) : 자동 주입할 대상이 없으면 해당 객체의 메서드 호출이 안되도록 막음.
• org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
• Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다

// Member라는 스프링 빈 스프링 컨테이너에 없다 = 자동 의존주입이 불가능하다.
//호출 안됨, 실행조차 되지 않고 무시됨 (Member는 스프링빈이 아닌 그냥 자바객체이므로)
@Autowired(required = false)
public void setNoBean1(Member member){
        System.out.println("setNoBean1 = "+member);
}
        
//null 호출
@Autowired
public void setNoBean2(@Nullable Member member){
        System.out.println("setNoBean2 = "+member);
}
        
//Optional.empty 호출
@Autowired(required = false)
public void setNoBean3(Optional<Member> member){
        System.out.println("setNoBean3 = "+member);
}

// setNoBean1()은 호출자체가 안됨.
setNoBean2 = null
setNoBean3 = Optional.empty

 

---

# final 키워드의 사용

생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있다. 이를 이용하면 생성자에서 혹시라도 값이 초기화(설정)되지 않는 오류를 컴파일 시점에 막아줄 수 있게 된다.

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
 
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
    }
    //...
}