[강의] 스프링 핵심 원리 - 기본편 3

이번주 양 많다... 화이팅

inf.run/wr1v

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

출처:  김영한 강사님 스프링 핵심 원리-  기본편

 

4.스프링 컨테이너와 스프링 빈

- 스프링 컨테이너 생성

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext <- 스프링 컨테이너, 인터페이스

 

스프링 컨테이너는 주로 애노테이션 기반의 자바 설정 크래스로 만든다 (XML로 만들기도, 잘 안씀)

스프링 컨테이너 생성

-> 파라미터로 넘어온 설정 클래스 정보를 구성 정보로 사용하여
    애노테이션 붙은 것들을 찾아다니면서 스프링 빈 등록

    * 빈 이름은 모두 달라야한다.

-> 스프링 컨테이너가 설정 클래스 정보를 참고하여 의존관계 주입

 

- 컨테이너에 등록된 모든 빈 조회

ApplicationContextInfoTest.java로 조회한다.

이렇게 하면 우리가 짠 코드에서 쓰이는 것 뿐 아니라 스프링 내부의 빈까지 다 나온다.

아래 다섯개 순서대로 AppConfig, 등록한 빈들

 

따라서 아래에 우리가 짠 코드에서 쓰이는 것들만 출력하도록 만들었다.

잘 나온다.

 

ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름 조회
ac.getBean(빈 이름) : 빈 이름으로 빈 객체 조회

 

getRole() ->
ROLE_APPLICATION : 사용자 정의 빈
ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈

 

soutv 값 System.out.println으로 출력

ctrl + D 복제

 

- 스프링 빈 조회 - 기본

getBean을 사용하는 3가지 방법

1) 빈 이름으로 조회

2) 타입으로만 조회

3) 구체 타입으로 조회

//ApplicationContextBasicFindTest.java
public class ApplicationContextBasicFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName(){
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("이름 없이 타입으로만 조회")
    void findBeanByType(){
        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2(){
        MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class);
        //좋은 방법은 아니다. 어쨌든 등록한 반환타입 뿐 아니라 구체화 타입으로 해도 상관이 없다.
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("빈 이름으로 조회했는데 없는 이름")
    void findBeanByNameX(){
        /*MemberService memberService = ac.getBean("xxxx", MemberService.class);
        //No bean named 'xxxx' available 오류 뜬다.*/
        org.junit.jupiter.api.Assertions.assertThrows(NoSuchBeanDefinitionException.class,
                () -> ac.getBean("xxxx", MemberService.class));

    }
}

 

- 스프링 빈 조회 - 동일한 타입이 둘 이상

AppConfig를  새로 만들어서 아까와 같은 방식으로 테스트 하면 하나만 찾아져야 하지만 두개가 찾아졌다는 오류가 뜬다.

//ApplicationContextSameBeanFindTest.java
public class ApplicationContextSameBeanFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SameBeanConfig.class);

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 중복 오류가 발생한다.")
    void findBeanByTypeDuplicate(){
        //MemberRepository bean = ac.getBean(MemberRepository.class);
        Assertions.assertThrows(NoUniqueBeanDefinitionException.class,
                () -> ac.getBean(MemberRepository.class));
    }

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 빈 이름을 지정하면 된다.")
    void findBeanName(){
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);
        assertThat(memberRepository).isInstanceOf(MemberRepository.class);
    }

    @Test
    @DisplayName("특정 타입을 모두 조회하기")
    void findAllBeanByType(){
        Map<String, MemberRepository> beansOfType = ac.getBeansOfType(MemberRepository.class);
        for(String key : beansOfType.keySet()){
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
        System.out.println("beansOfType = " + beansOfType);
        assertThat(beansOfType.size()).isEqualTo(2);
    }


    //AppConfig 중복 있는 걸로 새로 만들기
    @Configuration
    static class SameBeanConfig{

        @Bean
        public MemberRepository memberRepository(){
            return new MemoryMemberRepository();
        }

        @Bean
        public MemberRepository memberRepository2(){
            return new MemoryMemberRepository();
        }

    }
}

같은 타입이 둘 이상일 경우, 받을 빈 이름을 직접 정하고 타입으로 조회하면 Map클래스가 나온다.

유일하게 출력이 있었던 메소드 출력 잘됨

 

- 스프링 빈 조회 - 상속 관계

대원칙 : 부모 타입으로 조회하면 자식 타입은 함께 조회된다.

//ApplicationContextExtendsFindTest.java
public class ApplicationContextExtendsFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
    
    @Test
    @DisplayName("부모 타입으로 조회시 자식이 둘 이상 있으면 중복 오류가 발생한다")
    void findBeanByParentTypeDuplicate(){
        assertThrows(NoUniqueBeanDefinitionException.class,
                () -> ac.getBean(DiscountPolicy.class));
    }

    @Test
    @DisplayName("부모 타입으로 조회시 자식이 둘 이상 있으면 빈 이름을 지정하면 된다")
    void findBeanByParentTypeBeanName(){
        DiscountPolicy rateDiscountPolicy = ac.getBean("rateDiscountPolicy", DiscountPolicy.class);
        assertThat(rateDiscountPolicy).isInstanceOf(RateDiscountPolicy.class);
    }

    @Test
    @DisplayName("특정 하위 타입으로 조회")
    void findBeanBySubType(){
        RateDiscountPolicy bean = ac.getBean(RateDiscountPolicy.class);
        assertThat(bean).isInstanceOf(RateDiscountPolicy.class);
        //구체적인 rate어쩌구는 하나밖에 없기 때문에 타입으로 한번에 잘 찾을 수 있다.
    }

    @Test
    @DisplayName("부모 타입으로 모두 조회")
    void findAllBeanByParentType(){
        Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
        assertThat(beansOfType.size()).isEqualTo(2);
        for(String key : beansOfType.keySet()){
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
    }

    @Test
    @DisplayName("부모 타입으로 모두 조회 - Object Type")
    void findAllBeanByObjectType(){
        Map<String, Object> beansOfType = ac.getBeansOfType(Object.class);
        for(String key : beansOfType.keySet()){
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
    }


    @Configuration
    static class TestConfig{
        
        @Bean
        public DiscountPolicy rateDiscountPolicy(){
            return new RateDiscountPolicy();
        }

        @Bean
        public DiscountPolicy fixDiscountPolicy(){
            return new FicDiscountPolicy();
        }
    }
}

부모 타입으로 모두 조회 아주 잘 됨

코드에 있는 것 뿐 아니라 스프링 내부의 빈까지 우르르~ 모두 Object의 하위 객체이기 때문이다.

 

- BeanFactory와 ApplicationContext

BeanFactory
스프링 컨테이너의 최상위 인터페이스
스프링 빈 관리, 조회

↓상속

ApplicationContext
BeanFactory 기능을 모두 상속받아서 제공

하지만 BeanFactory 뿐 아니라 많은 다른 기능들도 상속받는다.

애플리케이션 개발에는 BeanFactory 외에도 수 많은 부가기능이 필요하기 때문이다.

• MessageSource
  국제화 ex) 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력
• EnviromentCapable
  환경 변수. 로컬, 개발, 운영등을 구분해서 처리 ex) 환경 별로 어떤 DB에 연결하는지
• ApplicationEventPublisher
  이벤트를 발행하고 구독하는 모델을 편리하게 지원
• ResourseLoader
  파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

- 다양한 설정 형식 지원 - 자바 코드, XML

자바 코드 뿐 이니라 XML 등 다양한 형식을 지원한다.

ApplicationContext을

1) AnnotationConfigApplicationContext에 자바 코드 넘기기

2) GenericXmlApplication에 xml 파일 넘기기 <- 현재는 거의 사용되지 않음

<!--appConfig.xml-->
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="memberService" class="hello.core.member.MemberServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository" />
    </bean>

    <bean id="memberRepository"
          class="hello.core.member.MemoryMemberRepository" />

    <bean id="orderService" class="hello.core.order.OrderServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository" />
        <constructor-arg name="discountPolicy" ref="discountPolicy" />
    </bean>

    <bean id="discountPolicy" class="hello.core.discount.RateDiscountPolicy" />
</beans>

잘 보면 AppConfig.java 랑 완전 똑같은 것을 알 수 있다.

ApplicationContext ac = new GenericXmlApplicationContext("appConfig.xml");로만 바꿔서 똑같이 테스트하면 잘 된다!

 

- 스프링 빈 설정 메타 정보 - BeanDefinition

스프링 컨테이너는 자바 코드인지, XML인지 몰라도 된다.
이렇게 다양한 방법을 지원하는 이유는 모두 BeanDefinition이라는 추상화로 인식하기 때문이다.

BeanDefinition을 설정 메타 정보라고 한다. @Bean당 하나의 메타정보를 만들어낸다.

app config 파일의 형식에 맞는 reader로 설정 정보를 읽고 빈 메타정보를 생성한다.

//BeanDefinitionTest.java
public class BeanDefinitionTest {
    AnnotationConfigApplicationContext ac =new AnnotationConfigApplicationContext(AppConfig.class);
    //GenericXmlApplicationContext ac = new GenericXmlApplicationContext("appConfig.xml");

    @Test
    @DisplayName("빈 설정 메타정보 확인")
    void findApplicationBean(){
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for(String beanDefinitionName : beanDefinitionNames){
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);
            if(beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION){
                System.out.println("beanDefinition = " + beanDefinition
                + " beanDefinition = " + beanDefinition);
            }
        }
    }
}

빈을 등록하는 방법은 직접등록, Factory 메소드를 이용하는 방법이 있는데.

저장되는 형식이 조금 다름

 

5.싱글톤 컨테이너

- 웹 애필리케이션과 싱글톤

스프링은 주로 웹 애플리케이션에 사용되는데 웹은 보통 여러 고객이 동시에 요청한다.

->요청이 올 때마다 객체를 새로 만드는가?

yes 두개 생성됨

하지만 같은 객체 여러개가 매번 생기는 것은 메모리 낭비!

-> 하나의 객체로 공유하도록 : 싱글톤 패턴

 

- 싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

-> 두개이상 생성되지 못하도록 막는다.

//SingletonService.java
public class SingletonService {

    //static에 객체 올려두기
    private static final SingletonService instance = new SingletonService();

    //조회
    public static SingletonService getInstance(){
        return instance;
    }

    //생성자를 private로 막는다 ***
    private SingletonService(){ }

    public void logic(){
        System.out.println("싱글톤 객체 로직 호출");
    }
}

 

이제 두 객체가 같은 것을 볼 수 있다!

하지만 단점  :

코드가 많이 들어감(Singleton Service)

클라이언트가 구체 클래스에 의존 DIP, OCP위반

테스트하기 어려움

private를 사용함으로써 유연성이 떨어짐

등등 갖가지 단점들이 있다.

 

그러나!! 스프링 컨테이너를 사용하면 싱글톤을 알아서 구현해준다!!

 

- 싱글톤 컨테이너

Bean을 생각해보면, 스프링은 한 클래스 당 객체 하나씩만 등록해서 관리한다.

스프링 컨테이너로 사용하는 싱글톤은 위의 단점들을 모두 해결할 수 있다.

같은 객체임을 확인할 수 있다.

스프링은 싱글톤 뿐 아니라 매번 새로운 객체를 생성해 반환하는 기능도 제공한다.

 

- 싱글톤 방식의 주의점

여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다.

-> 무상태 설계
특정 클라이언트에 의존적이면 안됨
특정 클라이언트가 값 수정이 불가능해야함, 읽기만 가능하면 좋음

필드 대신 지역번수, 파라미터, ThreadLocal등을 사용해야 함

 

문제 상황

//StatefulService.java
public class StatefulService {

    private int price;

    public void order(String name, int price){
        System.out.println("name = " + name + " price = " + price);
        this.price = price;
    }

    public int getPrice(){
        return price;
    }
}

//StatefulServiceTest.java
public class StatefulServiceTest {

    @Test
    void statefulServiceSingleton(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

        //ThreadA: A가 10000원 주문
        statefulService1.order("userA", 10000);
        //ThreadB: B가 20000원 주문
        statefulService2.order("userB", 20000);

        //ThreadA: A 주문 금액 조회
        int price = statefulService1.getPrice();
        System.out.println("price = " + price);

        //중간에 사용자 B가 바꾸어버렸으므로 price는 20000원이 나오게 된다.
        //같은 객체이므로 생기는 문제
        Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);

    }

    static class TestConfig{

        @Bean
        public StatefulService statefulService(){
            return new StatefulService();
        }
    }
}

안돼!! userA는 이만원짜리를 주문하지 않았어!!

해결

//StatefulService.java
public class StatefulService {
    public int order(String name, int price){
        System.out.println("name = " + name + " price = " + price);
        return price;
    }
}

//StatefulServiceTest.java
public class StatefulServiceTest {

    @Test
    void statefulServiceSingleton(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

        //ThreadA: A가 10000원 주문
        int userAPrice = statefulService1.order("userA", 10000);

        //ThreadB: B가 20000원 주문
        int userBPrice = statefulService2.order("userB", 20000);

        //ThreadA: A 주문 금액 조회
        System.out.println("price = " + userAPrice);

        //문제가 발생하지 않는다.
        Assertions.assertThat(userAPrice).isEqualTo(10000);

    }

    static class TestConfig{

        @Bean
        public StatefulService statefulService(){
            return new StatefulService();
        }
    }
}

편-안

- @Configuration과 싱글톤

memberService 빈 -> memberRepository() 호출 -> MemoryMemberRepository() 호출
orderService 빈 -> memberRepository() 호출 -> MemoryMemberRepository() 호출

=> 싱글톤이 깨지는 게 아닌가?!

하지만 스프링은 싱글톤을 보장해준다.

//MemberServiceImpl.java
public class MemberServiceImpl implements MemberService{
	/*생략*/
    public MemberRepository getMemberRepository(){
        return memberRepository;
    }
}
//OrderServiceImpl.java
public class OrderServiceImpl implements OrderService{
    /*생략*/
    public MemberRepository getMemberRepository(){
        return memberRepository;
    }
}

//ConfigurationSingletonTest.java
public class ConfigurationSingletonTest {

    @Test
    void configurationTest(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        //memberService 호출 memberRepository
        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
        //orderService 호출 memberRepository
        OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
        //처음에 빈에 등록된 memberRepository
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();

        System.out.println("memberService -> memberRepository = " + memberRepository1);
        System.out.println("orderService -> memberRepository = " + memberRepository2);
        System.out.println("memberRepository = " + memberRepository);

        assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
        assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);
    }
}

세개 모두 같다...!

 

AppConfig의 DP을 제외한 각 Bean에 호출될 때마다 출력되는 call+soutm문장을 넣어놓았다.

그리고 출력하니 예상(등록 MS->MR, 등록 MR, 등록 OS->MR)과 다르게 나온다!

각 한 번 씩 세 번만 나오고 만다!

 

- @Configuration과 바이트코드 조작의 마법

스프링 컨테이너는 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그러나 자바 코드를 어떻게 하기는 어렵다.

Appconfig가 아닌 뒤에 이상한게 붙은 클래스가 출력된다.

이런 임의의 다른 클래스가 싱글톤을 보장해준다.(CGLIB) <- 이는 자식 타입이다.

얘가 스프링 빈이 이미 있으면 스프링 빈 반환, 없으면 등록하는 역할을 한다.

또한 뒤에 이상한 이름이 붙은 클래스여도, 원래 클래스 이름으로 조회 가능함

이는 @Configuration 덕분이다.

 

@Configuration을 적용하지 않는다면, 싱글톤이 보장되지 않는다!

순수한 AppConfig에 접근하여 @Bean들은 인식해서 등록함

아까 예상했던 등록 MS->MR, 등록 MR, 등록 OS->MR, 즉, MemberRepositiory가 세번 출력된다.

-> 싱글톤이 보장되지 않는다!, 스프링 컨테이너와 관련이 없어짐

전부 실행시켜보면 세번 만들어지는 MemberRepositiory의 인스턴스가 각각 다 다른 것 또한 알 수 있다.

@Autowired쓰기도 하고 어쩌긴 하지만 그래도

결론 : 있어야 함

 

6.컴포넌트 스캔

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

@Bean으로 일일히 등록하는 것은 스프링 빈이 많아지면 힘들어짐

   ->Component scan, Autowired

//AutoAppConfig.java
@Configuration
@ComponentScan(
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
        //예제 유지 위해 제외할 것들 설정, Appconfig 랑 부딪힐까봐 일단 설정
)
public class AutoAppConfig { }

이는 @Component가 붙은 클래스를 스캔해서 스프링 빈으로 등록한다.

//AutoAppConfigTest.java
public class AutoAppConfigTest {

    @Test
    void basicScan(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class);

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

MemoryMemberRepository @Component 추가
RateDiscountPolicy @Component 추가
MemberServiceImpl @Component, 생성자에 @Autowired 추가(의존 관계 주입)

OrderServiceImpl @Component, 생성자에 @Autowired 추가

그리고 테스트를 해본다.

//AutoAppConfigTest.java
public class AutoAppConfigTest {

    @Test
    void basicScan(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class);

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

잘 돌아가는 것을 알 수 있다.

빈에 올라가는 이름을 바꾸고 싶으면 @Component(바꾸고 싶은 이름)하면 된다. (기본은 맨앞만 소문자인 클래스 이름)

@ComponentScan은 @Component 가 붙은 모든 클래스를 스프링 빈으로 등록한다.

 

@Autowired는스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입

ex) OrderServiceImpl의 생성자 파라미터 memberRepository와 discountPolicy같은 애들은 이미 있는 것이니까

해당 스프링 빈을 찾아서 주입. getBean재질

 

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

@ComponentScan(
    basePackages = "탐색할 패키지의 탐색 시작 위치 (Default : @ComponentScan 이 붙은 설정 정보 클래스의 패키지)",

    basePackageClasses = 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다.
}

Springboot에서는 @SpringBootApplication이 자동으로 생성되는데, 그 아래에는 ComponentScan이 있음

-> 쓸 필요 없음

 

@Component : 컴포넌트 스캔에서 사용
@Controlller : 스프링 MVC 컨트롤러에서 사용
@Service : 스프링 비즈니스 로직에서 사용 (별 기능은 없음, 보기 좋음)
@Repository : 스프링 데이터 접근 계층에서 사용, 데이터 계층의 예외를 스프링 예외로 변환
@Configuration : 스프링 설정 정보에서 사용, 스프링 빈이 싱글톤을 유지하도록 추가 처리

-> 이 것들 아래에 전부 @Component있음

 

자바에는 에노테이션 상속 기능이 없으므로 이걸 할 수 있는 것은 스프링이 지원하는 기능이다.

 

- 필터

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

 

스캔 대상/ 제외 애노테이션 

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

//MyExcludeComponent.java
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent { }

스캔 대상 클래스(BeanA)에는 @MyIncludeComponent를,

스캔 제외 클래스(BeanB)에는 @MyExcludeComponent를 붙여줍니다.

 

설정 정보와 스캔 대상/제외 테스트 코드

//ComponentFilerAppConfigTest.java
public class ComponentFilerAppConfigTest {
    @Test
    void filterScan(){
        ApplicationContext 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(
        includeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyIncludeComponent.class),
        excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = MyExcludeComponent.class)
    )

    static class ComponentFilterAppConfig { }
}

제외된 B는 getBean이 안되므로 assertTrows에 넣는다.

A는 포함되었기에 Null이 아니므로 오류가 나지 않는다.

 

- 중복 등록과 충돌

FilterType. ANNOTATION: 기본값, 애노테이션을 인식해서 동작한다.(생략해도 됨)
                 ASSIGNABLE_TYPE: 지정한 타입과 자식 타입을 인식해서 동작한다.
                 ASPECTJ: AspectJ 패턴 사용
                 REGEX: 정규 표현식
                 CUSTOM: TypeFilter 이라는 인터페이스를 구현해서 처리

 

중복등록

자동 빈 등록 vs 자동 빈 등록 - 알아서 오류남
ex) @Component("service") 달린 클래스가 두 개임

수동 빈 등록 vs 자동 빈 등록 - 수동이 자동을 오버라이딩 한다.

ex) @Component달린 클래스과 @Bean("앞 클래스 이름") - 후자가 전자 오버라이드

=> 피하는 게 좋다, 애매한 상황을 굳이 만들 필요가 있나?

였는데, 최근 스프링부트에서는 수동& 자동이 충돌하면 기본값으로 오류가 발생하도록 변경함

- 발생하지 않도록 할 수는 있음 하지만 어쨌든 이름 겹치는건 별로임