[Spring] 스프링 컨테이너와 스프링 빈

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

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

 

스프링 컨테이너 생성

 

스프링 컨테이너라 불리는 ApplicationContext가 생성되는 과정에 대해 생각해보자

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

ApplicationContext의 코드를 까보면 다음과 같다.

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
      MessageSource, ApplicationEventPublisher, ResourcePatternResolver {

• ApplicationContext는 인터페이스 - 다형성 적용
• XML 기반으로도 만들 수 있고, 애노테이션 기반의 자바 설정 클래스(이전의 AppConfig 형식)로도 만들 수 있다. 

더 정확히는 스프링 컨테이너를 부를 때 BeanFactory, ApplicationContext로 구분해서 부르지만 BeanFactory는 거의 사용하지 않기 때문에 일반적으로 ApplilcationContext를 스프링 컨테이너라고 한다.

 

 

스프링 컨테이너 생성 과정

1. 스프링 컨테이너 생성 : new AnnotationConfigApplicationContext(AppConfig.class);

스프링 컨테이너를 생성할 때에는 구성 정보를 지정해주어야 하는데 여기서는 AppConfig.class를 구성 정보로 지정했다. 스프링 컨테이너는 이 AppConfig.class의 정보를 보고 생성해야 하는 객체들을 인지한다.

 

 

2. 스프링 빈 등록

전달받은 AppConfig.class 정보를 사용해 스프링 빈을 등록한다.

 

@Bean이 붙은 메서드를 전부 호출해서 메서드 이름을 key로 지정하고 return으로 나오는 객체를 key에 대한 값으로 빈 객체를 설정한다. 

 

• 빈 이름은 메서드 이름을 사용
• @Bean(name="memberService2")로 직접 설정 가능
• 빈 이름이 중복되면 다른 빈이 무시되거나 기존 빈을 덮어버리기 때문에 빈 이름은 항상 다른 이름을 부여해야 한다.
  • 최근 스프링부트는 기본 옵션으로 빈 이름이 충돌되면 경고와 함께 오류를 내준다. 

 

3. 스프링 빈 의존관계 설정 : AppConfig 설정 정보를 참고하여 의존관계를 주입(DI)한다. 

스프링은 빈을 생성하고 의존관계를 주입하는 단계가 나누어져 있다.

 

이렇게 위의 new AnnotationConfigApplicationContext(AppConfig.class) 자바 코드로 스프링 빈을 등록하면 생성자를 호추하면서 의존관계 주입도 한번체 처리된다.

 

 

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

스프링 빈들의 조회를 통해 등록이 잘 되었는 지 확인한다.

getRole()을 통해 스프링이 내부에서 사용하는 빈을 구분할 수 있다.

 

 

모든 빈 출력하는 findAllBean() Test 결과

 

애플리케이션 빈 출력하는 findApplicationBean() Test 결과

 

스프링 빈 조회 - 기본

getBean을 통해 타입으로 스프링 빈을 찾을 수 있었다. 

 

만약 조회 대상 스프링 빈이 없으면 예외가 발생한다. 

 

 

 

 

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

getBean으로 조회 시 해당 타입의 빈이 하나가 아니라 둘 이상이라면 NoUniqueBeanDefinitionException 오류가 발생한다. 

 

 

 

스프링 빈 조회 - 상속관계

 

스프링 빈을 조회할 때의 대원칙은 부모 타입을 조회할 경우 자식 타입을 전부 조회한다. 따라서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면 모든 스프링 빈을 조회할 수 있다.

 

• Object로 조회 시 : Object, 1, 2, 3, 4, 5
• 1로 조회 시 : 1, 3, 4
• 2로 조회 시 : 2, 5

예제의 DiscountPolicy를 생각해보면 부모 타입인 DiscountPolicy 인터페이스로 빈을 조회해도 구현체들이 모두 조회 되었다.

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

    @Test
    @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 중복 오류 발생")
    void findBeanByParentTypeDuplication() {
        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);
        System.out.println("beansOfType = " + beansOfType);
        
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + "value = " + beansOfType.get(key));
        }
    }

    @Test
    @DisplayName("부모 타입으로 모두 조회하기 - Object")
    void findAllBeanByObjectTest() {
        // 스프링 내부적으로 사용되는 빈과 함께 TestConfig에서 등록한 빈들이 전부 조회된다.
        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();
        }
    }



}

실제 테스트에서는 테스트 실행 후 눈으로 전부 확인할 수 없으니까 sout 출력물을 내는 테스트 말고 시스템이 자동으로 실패를 결정할 수 있는 테스트가 효율적이다.

 

 

BeanFactory와 ApplicationContext 

BeanFactory는 스프링 컨테이너의 최상위 인터페이스로 스프링 빈을 조회하는 역할을 한다. 예제에서 사용한 대부분의 기능은 BeanFactory가 제공하는 기능이다.

ApplicationContext는 BeanFactory 기능을 모두 상속받아서 제공하는 것으로 거기에 더해 수 많은 부가 기능을 제공한다. 따라서 BeanFactory를 직접 사용하지 않고 부가 기능이 포함된 ApplicationContext를 사용한다.

개발할 때 크게 3가지 환경이 있다.
1. 로컬 (내 pc)
2. 여러 시스템을 엮어서 실제 테스트 서버에 띄워두고 테스트할 수 있는 개발 환경
3. 실제 프로덕션이 나가는 운영환경

 

 

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

예제를 통해 자바 코드로 스프링 컨테이너를 설정했다. 스프링 컨테이너는 다양한 형식의 설정 정보를 받아드릴 수 있게 유연하게 설계되어 있기 때문에 자바뿐만 아니라 XML, Groovy 등 다양한 형식을 지원한다.

 

 

 

 

XML 설정 사용 

최근 스프링 부트를 사용하면서 XML기반 설정은 잘 사용하지 않지만 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점이 있으니 알아두자

 

public class XmlAppContext {
    @Test
    void xmlAppContext() {
        ApplicationContext ac = new
                GenericXmlApplicationContext("appConfig.xml");

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

 

xml 기반의 스프링 빈 설정 정보 : AppConfig.java의 설정 정보와 거의 비슷하다.

 

 

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

java, xml 등 다양한 설정 형식을 모두 지원하는 데에 가장 큰 역할은 BeanDefinition이라는 추상화이다. BeanDefinition은 빈 정보에 관한 것을 전부 추상화 시킨 것으로 @Bean 또는 <bean>당 각각 하나씩 메타 정보를 생성해서 추상화하는 것이다. 이를 통해 역할과 구현을 개념적으로 나누는 효과가 발생한다.

XML이든 java 코드든 읽어서 BeanDefinition을 만들면 스프링은 자바 코드인지 XML 코드인지 알 필요 없이 오직 BeanDefiniton만 알면 된다. 스프링 컨테이너는 이 BeanDefinition이라는 메타 정보를 기반으로 스프링 빈을 생성한다.

 

 

다양한 형식의 설정정보를 BeanDefinition으로 추상화하는 과정은 다음과 같다

 

 

BeanDefinition Test

beanDefinitionName = appConfigbeanDefinition = Generic bean: class [hello.core.AppConfig$$EnhancerBySpringCGLIB$$7afd499e]; scope=singleton; abstract=false; lazyInit=null; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null
beanDefinitionName = memberServicebeanDefinition = Root bean: class [null]; scope=; abstract=false; lazyInit=null; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=appConfig; factoryMethodName=memberService; initMethodName=null; destroyMethodName=(inferred); defined in hello.core.AppConfig
beanDefinitionName = memberRepositorybeanDefinition = Root bean: class [null]; scope=; abstract=false; lazyInit=null; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=appConfig; factoryMethodName=memberRepository; initMethodName=null; destroyMethodName=(inferred); defined in hello.core.AppConfig
beanDefinitionName = orderServicebeanDefinition = Root bean: class [null]; scope=; abstract=false; lazyInit=null; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=appConfig; factoryMethodName=orderService; initMethodName=null; destroyMethodName=(inferred); defined in hello.core.AppConfig
beanDefinitionName = discountPolicybeanDefinition = Root bean: class [null]; scope=; abstract=false; lazyInit=null; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=appConfig; factoryMethodName=discountPolicy; initMethodName=null; destroyMethodName=(inferred); defined in hello.core.AppConfig

 

BeanDefinition 정보
-  BeanClassName : 생성할 빈의 클래스명
-  factoryBeanName : 팩토리 역할의 빈을 사용할 경우 (appConfig)
-  factoryMethodName : 빈을 생성할 팩토리 메서드 지정 (memberService)
-  Scope : 싱글톤(기본값)
-  lazyInit : 스프링 컨테이너를 생성할 때 빈을 생성하는 것이 아닌 실제 빈을 사용할 때까지 최대한 생성을 지연처리 하는지 여부
-  InitMethodName : 빈을 생성하고, 의존관계를 적용한 뒤에 호출되는 초기화 메서드 명
-  DestroyMethodName : 빈의 생명주기가 끝나서 제거하기 직전에 호출되는 메서드 명
-  Constructor arguments, Properties : 의존 관계 주입에서 사용 (자바 설정처럼 팩토리 역할의 빈을 사용하면 없음)

 

실무에서 BeanDefinition을 직접 생성해서 사용할 일은 거의 없으므로 참고만 하자^^

​