#6. 스프링 컨테이너와 스프링 빈

앞에서 스프링이 나오게된 개념에 대해 알아보았다면, 이번 글부터는 스프링 자체가 어떻게 동작하는지 알아보자.

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

 

# 스프링 컨테이너

//스프링 컨테이너 생성
ApplicationContext applicationContext =
 new AnnotationConfigApplicationContext(AppConfig.class);

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
    ... 생략...
}

• ApplicationContext 를 스프링 컨테이너라 한다.
• ApplicationContext 는 인터페이스이다.
• 참고로 스프링 컨테이너는 보통 어노테이션(@) 기반의 자바 클래스로 만들지만, 기존에 서블릿을 설정하던 것처럼 XML 기반으로도 만들 수 있다.
• 자바 설정 클래스를 기반으로 스프링 컨테이너(ApplicationContext)를 만들어보자.
  - new AnnotationConfigApplicationContext(appConfig.class)
  - 이 클래스는 ApplicationContext 인터페이스의 구현체이다.

참고로 정확히는 스프링 컨테이너를 부를 때 최상위의 BeanFactory와 자식인 ApplicationContext를 구분해서 사용하지만, 이는 나중에 알아보도록 하자. (보통 BeanFactory를 직접 사용하는 경우는 거의 없고, AppContext를 스프링 컨테이너라고 한다.)

 

---

# 스프링 컨테이너의 생성과정

@1 컨테이너 생성

ApplicationContext라는 인터페이스에 구현체를 등록해줘서 사용한다. 스프링 컨테이너를 생성 할 때에는 구성 정보를 구현체에 지정해주어야 하는데, 여기에서는 AppConfig.class를 이용하여 [자바의 Class 객체]를 통해 구성정보를 지정하였다. Class 객체가 뭐죠?

자바는 Object.class 를 통해 해당 객체의 Class 객체를 받을 수 있다.

Class.forName("패키지 전체 경로") 
클래스이름.class

MyHello.class
Class.forName("mypackage.core.MyHello")

Class 클래스란 자바에서 사용되는 클래스에 대한 구조를 가지고, 이를 저장하여 넘겨줄 수 있는 객체이다.즉 쉽게말해 [클래스의 구조] 자체를 하나의 클래스로 표현해놓은 객체라는 말이다.

클래스의 정보를 저장할 수 있는 Class 객체

참고로 이렇게 객체를 통해 [다른 객체]의 정보를 분석하는 방식을 Reflection 기법이라고 한다. 클래스 파일의 위치나 이름만으로도 해당 클래스의 정보를 가져와 객체를 생성할 수 있게(Hello.class) 만들어주는 유연한 프로그래밍 기법이다. 스프링 프레임워크에서도 리플렉션 기법을 아주 많이 사용있는 걸 볼 수 있다.  

 

ApplicationContext applicationContext =
 new AnnotationConfigApplicationContext(AppConfig.class);

 

---

@2 스프링 빈 등록

컨테이너에 파라메타로 넘겨준 객체(AppConfig.class)에서 @Bean 으로 등록된 메서드를 전부 호출하여 반환 값을 스프링 빈 저장소에 모아둔다. 빈 이름은 메서드 명으로 지정되며 원한다면 바꿀 수 있긴하다. @Bean(name="...") 참고로 빈의 이름은 항상 다르게 부여해주어야하는데, 같은 이름을 부여하면 빈 저장소에있는 기존의 빈을 덮어버리거나 무시되어 오류가 발생할 수 있기 때문이다. (* 요즘은 스프링 부트가 이런 설정 실수를 오류로 개발자에게 알려준다. )

 

---

@3 스프링 빈 의존관계 설정

저장소에 등록된 빈들의 의존관계를 주입한다. 실제 스프링 빈에서 의존관계인 객체의 참조 값들이 연결된다. 연결이라는게 단순히 자바 메서드를 호출해서 생성하는 것처럼 보일 수 있지만, 이와는 차이가 있다. (*싱글톤 컨테이너)

이처럼 스프링은 빈을 생성하는 단계와 의존관계를 주입하는 단계가 나누어져 있다. 하지만 위의 예제처럼 자바 코드로 스프링빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리되는데, 이는 나중에 '의존관계 자동 주입'을 배우면서 알아보도록 하자.

 

---

# 컨테이너에 등록된 스프링 빈 조회하기

테스트 코드(JUnit5)를 이용해 스프링 컨테이너에 등록된 데이터를 확인해보자. 참고로 등록된 빈들의 이름은 AppContext 객체의 메서드로 얻어올 수 있다. 내가 등록한 빈 이외에 스프링에서 기본적으로 사용하는 빈들도 있음을 유의하자.

class ApplicationContextInfoTest {
    AnnotationConfigApplicationContext ac = new
            AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력하기")
    void findAllBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name=" + beanDefinitionName + " object=" + bean);
        }
    }
}

 

또한 getBeanDefinition을 비교해서 내가 등록한 어플리케이션 빈(appConfig, memberService...)만 확인할수도 있다.

import org.springframework.beans.factory.config.BeanDefinition;

    @Test
    @DisplayName("애플리케이션 빈 출력하기")
    void findApplicationBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition =
                    ac.getBeanDefinition(beanDefinitionName);
            //Role ROLE_APPLICATION: 직접 등록한 애플리케이션 빈
            //Role ROLE_INFRASTRUCTURE: 스프링이 내부에서 사용하는 빈
            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                Object bean = ac.getBean(beanDefinitionName);
                System.out.println("name=" + beanDefinitionName + " object=" +
                        bean);
            }
        }
    }

 

---

@1 Bean 조회 - 기본

위에 테스트 케이스를 보면 알 수 있자만, 기본적으로 빈은 AppContext의 아래 메서드로 조회 할 수 있다. 만약 해당 빈이 존재하지 않는다면 NoSuchBeanDefinitionException 가 발생한다.

• getBean("Bean 이름", 타입)
• getBean(타입)

import org.junit.jupiter.api.Assertions; // Assertions가 같은 이름이 2개임을 유의하자.
import static org.assertj.core.api.Assertions.*;

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() {
        MemberServiceImpl memberService = ac.getBean("memberService",
                MemberServiceImpl.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("빈 이름으로 조회실패")
    void findBeanByNameX() {
        //ac.getBean("xxxxx", MemberService.class); 테스트
        Assertions.assertThrows(NoSuchBeanDefinitionException.class, () ->
                ac.getBean("xxxxx", MemberService.class));
    }
}

* 테스트 코드도 마찬가지로, 역할과 구현을 분리하는게 좋다. 위의 예제처럼 스프링 빈을 조회할 때 구현체를 이용해 구체적으로 조회하면 유연성이 떨어짐을 유의하자.

---

@2 Bean 조회 - 동일한 타입이 2개 이상인 경우

getBean을 이용해 타입으로 빈을 조회할 수 있다 했는데, 만약 타입이 같다면 어떻게 조회할 수 있을까? 이는 ac.getBeansOfType()을 이용하여 해당 타입의 모든 빈을 조회할 수 있다. 

 

* 테스트를 편하게 하기위해 코드안에 간단하게 테스트용 AppConfig 객체(SameBeanConfig)를 만들었다.

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

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

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 빈 이름을 지정하면 된다")
    void findBeanByName() {
        MemberRepository memberRepository = ac.getBean("memberRepository1",
                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);
        // 같은 타입은 2개여야 한다.
        assertThat(beansOfType.size()).isEqualTo(2);
    }
    
    // 테스트용 AppConfig 사용. 테스트라서 대충 만들었다.
    @Configuration
    static class SameBeanConfig {
        @Bean
        public MemberRepository memberRepository1() {
            return new MemoryMemberRepository();
        }

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

특정 타입을 모두 조회하기 결과

---

@3 Bean 조회 - 상속관계

부모 타입으로 조회하면, 자식 타입도 함께 조회한다. 즉 Object로 조회하면 모든 스프링 빈이 나오게 된다. 중복을 확인할 때 상속관계를 유의하여 테스트 코드를 작성하도록 하자. 

1번 객체의 빈을 조회하면, 모든 자식이 함께 반환된다.

class ApplicationContextExtendsFindTest {
    AnnotationConfigApplicationContext ac = new
            AnnotationConfigApplicationContext(TestConfig.class);

    @Test
    @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 중복 오류가 발생한다")
    void findBeanByParentTypeDuplicate() {
        //DiscountPolicy bean = ac.getBean(DiscountPolicy.class);
        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);
    }

    @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")
    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 FixDiscountPolicy();
        }
    }
}