목차
- 컴포넌트 스캔과 의존관계 자동 주입
- 탐색 위치와 기본 스캔 대상
- 필터 / 중복 등록과 충돌
그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능 제공
main > AutoAppConfig
@Configuration
@ComponentScan(
excludeFilters = @Filter(type = FilterType.ANNOTATION, classes =
Configuration.class))
public class AutoAppConfig {
}
컴포넌트 스캔을 사용 하기 위해 @ComponentScan을 설정 정보에 붙여줌
기존 AppConfig와는 다르게 @Bean으로 등록한 클래스가 하나도 없음.
컴포넌트 스캔은 @Component이 붙은 클래스를 스캔해서 스프링 빈으로 등록
-> 클래스에 @Component를 붙여주자
@Component
public class MemoryMemberRepository implements MemberRepository {}
@Component
public class RateDiscountPolicy implements DiscountPolicy {}
@Component
public class MemberServiceImpl implements MemberService {
private final MemberRepository memberRepository;
@Autowired
public MemberServiceImpl(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
}
@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;
}
}
이전에는 @Bean으로 직접 설정 정보를 작성 했으나, 이제는 이런 설정 정보 자체가 없기 때문에 의존관계 주입도 클래스 안에서 해결해야한다 ->@Autowired
@Autowired 를 사용하면 생성자에서 여러 의존관계도 한번에 주입받을 수 있음
테스트 진행
test > scan > AutoAppConfigTest
public class AutoAppConfigTest {
@Test
void basicScan() {
ApplicationContext ac = new
AnnotationConfigApplicationContext(AutoAppConfig.class);
MemberService memberService = ac.getBean(MemberService.class);
assertThat(memberService).isInstanceOf(MemberService.class);
}
}
- AnnotationConfigApplicationContext 를 사용하는 것은 기존과 동일
- 설정 정보로 AppConfig에서 AutoAppConfig를 넘겨줌
컴포넌트 스캔이 잘 동작하는 것을 확인
- @ComponentScan 은 @Component 가 붙은 모든 클래스를 스프링 빈으로 등록
- 이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용
- 빈 이름 기본 전략: MemberServiceImpl 클래스 -> memberServiceImpl
- 빈 이름 직접 지정: 만약 스프링 빈의 이름을 직접 지정하고 싶으면
@Component("memberService2") 이런식으로 이름을 부여
- 생성자에 @Autowired 를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입
- 이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입
- getBean(MemberRepository.class) 와 동일하다고 이해
모든 자바 클래스를 다 컴포넌트 스캔하면 시간이 오래걸리므로 필요한 위치부터 탐색 하는것이 좋음.
basePackages = "hello.core",
즐겨 사용하는 방법은 패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것
설명 추가 ###
컴포넌트 스캔은 @Component 뿐만 아니라 다음 항목들도 추가 대상에 포함
- @Component : 컴포넌트 스캔에서 사용
- @Controlller : 스프링 MVC 컨트롤러에서 사용
- @Service : 스프링 비즈니스 로직에서 사용
- @Repository : 스프링 데이터 접근 계층에서 사용
- @Configuration : 스프링 설정 정보에서 사용
@MyIncludeComponent
includeFilters : 컴포넌트 스캔 대상을 추가로 지정
@MyExcludeComponent
excludeFilters : 컴포넌트 스캔에서 제외할 대상 지정
includeFilters 를 사용할 일은 거의 없고 excludeFilters는 여러가지 이유로 간혹 사용할 때가 있지만 많지는 않음.
- ANNOTATION: 기본값, 애노테이션을 인식해서 동작
- ex) org.example.SomeAnnotation
- ASSIGNABLE_TYPE: 지정한 타입과 자식 타입을 인식해서 동작
- ex) org.example.SomeClass
- ASPECTJ: AspectJ 패턴
- ex) org.example..*Service+
- REGEX: 정규 표현식
- ex) org.example.Default.*
- CUSTOM: TypeFilter 이라는 인터페이스를 구현해서 처리
- ex) org.example.MyTypeFilter
컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록 되는데, 그 이름이 같은경우 오류 발생
ConflictingBeanDefinitionException 예외 발생
이런 경우에는 수동 빈 등록권이 우선권을 가짐
개발자가 의도적으로 이런 결과를 기대했다면, 자동 보다는 수동이 우선권을 가지는 것이 좋다. 하지만 현실은 개발자가 의도적으로 설정해서 이런 결과가 만들어지기 보다는 여러 설정들이 꼬여서 이런 결과가 만들어지는 경우가 대부분이다. -> 잡기 어려운 애매한 버그가 만들어짐...