The BeanFactory API

BeanFactory API는 Spring의 IoC 기능에 대한 기반을 제공합니다. 그 구체적인 contract들은 주로 Spring의 다른 부분 및 관련 third-party 프레임워크와의 통합에서 사용되며, 그 DefaultListableBeanFactory 구현체는 상위 수준의 GenericApplicationContext 컨테이너 내에서 핵심 delegate입니다.

BeanFactory 및 (BeanFactoryAware, InitializingBean, DisposableBean과 같은) 관련 인터페이스들은 다른 프레임워크 컴포넌트들을 위한 중요한 integration point입니다. 어떠한 어노테이션이나 리플렉션도 요구하지 않기 때문에, 이들은 컨테이너와 그 컴포넌트들 사이의 매우 효율적인 상호 작용을 가능하게 합니다.

Application 수준의 bean들도 동일한 callback 인터페이스를 사용할 수 있지만, 일반적으로는 어노테이션 또는 프로그래매틱 설정을 통한 선언적 의존성 주입을 선호합니다.

core BeanFactory API 수준과 그 DefaultListableBeanFactory 구현체는 사용될 설정 format이나 컴포넌트 어노테이션에 대해 어떠한 가정도 하지 않는다는 점에 유의해야 합니다. 이러한 모든 flavor들은 (XmlBeanDefinitionReader 및 AutowiredAnnotationBeanPostProcessor와 같은) extension을 통해 들어오며, core 메타데이터 표현으로서의 공유된 BeanDefinition 객체들에 대해 동작합니다.

이것이 Spring의 컨테이너를 그렇게 유연하고 확장 가능하게 만드는 본질입니다.

BeanFactory or ApplicationContext?

이 섹션은 BeanFactory와 ApplicationContext 컨테이너 수준의 차이점과 bootstrapping에 대한 영향을 설명합니다.

특별한 이유가 없다면 ApplicationContext를 사용해야 하며, custom bootstrapping을 위한 일반적인 구현체로는 GenericApplicationContext와 그 subclass인 AnnotationConfigApplicationContext가 있습니다.

이들은 모든 일반적인 목적을 위한 Spring core 컨테이너의 주요 entry point입니다: 설정 파일의 로딩, classpath scan 트리거, bean definition 및 어노테이션이 적용된 class의 프로그래매틱 등록, 그리고 (5.0부터는) functional bean definition의 등록 등입니다.

ApplicationContext는 BeanFactory의 모든 기능을 포함하므로, bean processing에 대한 완전한 제어가 필요한 시나리오를 제외하면 일반적으로 순수한 BeanFactory보다 권장됩니다.

ApplicationContext (예: GenericApplicationContext 구현체) 내에서는 여러 종류의 bean들이 관례에 따라 (즉, bean 이름이나 bean type — 특히 post-processor에 의해) 감지되는 반면, 순수한 DefaultListableBeanFactory는 어떤 special bean에 대해서도 agnostic합니다.

어노테이션 processing 및 AOP proxying과 같은 많은 확장 컨테이너 기능에 대해 BeanPostProcessor extension point는 필수적입니다.

순수한 DefaultListableBeanFactory만 사용하는 경우, 이러한 post-processor들은 기본적으로 감지되거나 활성화되지 않습니다. 이 상황은 bean 설정에는 실제로 아무 문제가 없기 때문에 혼란을 줄 수 있습니다. 오히려 이러한 시나리오에서는 컨테이너가 추가적인 setup을 통해 완전히 bootstrap되어야 합니다.

다음 표는 BeanFactory 및 ApplicationContext 인터페이스와 구현체가 제공하는 feature를 나열합니다.

Feature	BeanFactory	ApplicationContext
Bean instantiation/wiring	Yes	Yes
Integrated lifecycle management	No	Yes
Automatic BeanPostProcessor registration	No	Yes
Automatic BeanFactoryPostProcessor registration	No	Yes
Convenient MessageSource access (for internationalization)	No	Yes
Built-in ApplicationEvent publication mechanism	No	Yes

Table 1. Feature Matrix

DefaultListableBeanFactory에 bean post-processor를 명시적으로 등록하려면, 다음 예제에서 보듯이 프로그래매틱하게 addBeanPostProcessor를 호출해야 합니다:

1DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
2// populate the factory with bean definitions
3
4// now register any needed BeanPostProcessor instances
5factory.addBeanPostProcessor(new AutowiredAnnotationBeanPostProcessor());
6factory.addBeanPostProcessor(new MyBeanPostProcessor());
7
8// now start using the factory

1val factory = DefaultListableBeanFactory()
2// populate the factory with bean definitions
3
4// now register any needed BeanPostProcessor instances
5factory.addBeanPostProcessor(AutowiredAnnotationBeanPostProcessor())
6factory.addBeanPostProcessor(MyBeanPostProcessor())
7
8// now start using the factory

순수한 DefaultListableBeanFactory에 BeanFactoryPostProcessor를 적용하려면, 다음 예제에서 보듯이 그 postProcessBeanFactory 메서드를 호출해야 합니다:

1DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
2XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
3reader.loadBeanDefinitions(new FileSystemResource("beans.xml"));
4
5// bring in some property values from a Properties file
6PropertySourcesPlaceholderConfigurer cfg = new PropertySourcesPlaceholderConfigurer();
7cfg.setLocation(new FileSystemResource("jdbc.properties"));
8
9// now actually do the replacement
10cfg.postProcessBeanFactory(factory);

1val factory = DefaultListableBeanFactory()
2val reader = XmlBeanDefinitionReader(factory)
3reader.loadBeanDefinitions(FileSystemResource("beans.xml"))
4
5// bring in some property values from a Properties file
6val cfg = PropertySourcesPlaceholderConfigurer()
7cfg.setLocation(FileSystemResource("jdbc.properties"))
8
9// now actually do the replacement
10cfg.postProcessBeanFactory(factory)

두 경우 모두 명시적인 registration 단계는 불편하며, 이것이 다양한 ApplicationContext variant들이 Spring 기반 application에서 순수한 DefaultListableBeanFactory보다 선호되는 이유입니다.

특히 일반적인 enterprise setup에서 확장된 컨테이너 기능을 위해 BeanFactoryPostProcessor 및 BeanPostProcessor instance에 의존하는 경우에 그렇습니다.

AnnotationConfigApplicationContext는 모든 공통 어노테이션 post-processor가<br>등록되어 있으며, @EnableTransactionManagement와 같은 설정 어노테이션을<br>통해 내부적으로 추가적인 processor를 가져올 수 있습니다.<br>Spring의 어노테이션 기반 설정 model의 추상화 수준에서는,<br>bean post-processor의 개념이 단순한 내부 컨테이너 세부 사항이 됩니다.