Home [Spring] 1.16.1. BeanFactory or ApplicationContext?
Post
Cancel

[Spring] 1.16.1. BeanFactory or ApplicationContext?

1.16.1. BeanFactory or ApplicationContext?

This section explains the differences between the BeanFactory and ApplicationContext container levels and the implications on bootstrapping.

  • 이 섹션에서는 BeanFactoryApplicationContext 컨테이너 수준 간의 차이와 bootstrapping에 대한 함의(implications)를 설명한다.

You should use an ApplicationContext unless you have a good reason for not doing so, with GenericApplicationContext and its subclass AnnotationConfigApplicationContext as the common implementations for custom bootstrapping. These are the primary entry points to Spring’s core container for all common purposes: loading of configuration files, triggering a classpath scan, programmatically registering bean definitions and annotated classes, and (as of 5.0) registering functional bean definitions.

  • GenericApplicationContext 및 하위 클래스 AnnotationConfigApplicationContext를 사용자 지정 bootstrapping을 위한 일반적인 구현으로 사용할 수 없는 경우 ApplicationContext를 사용해야한다.
  • 구성 파일들 로드, 클래스 경로 스캔 트리거, 프로그래밍 방식으로 bean 정의 및 주석 처리된 클래스 등록, (5.0 기준) 기능 bean definitions 등록 등 모든 공통 목적을 위한 스프링 코어 컨테이너의 기본 진입점이다.

Because an ApplicationContext includes all the functionality of a BeanFactory, it is generally recommended over a plain BeanFactory, except for scenarios where full control over bean processing is needed. Within an ApplicationContext (such as the GenericApplicationContext implementation), several kinds of beans are detected by convention (that is, by bean name or by bean type — in particular, post-processors), while a plain DefaultListableBeanFactory is agnostic about any special beans.

  • ApplicationContextBeanFactory의 모든 기능을 포함하기 때문에 일반적으로 일반 BeanFactory보다 권장되지만, bean processing에 대한 완전한 통제가 필요한 시나리오는 제외한다.
  • ApplicationContext(예: GenericApplicationContext 구현) 내에서 여러 종류의 beans이 관습(즉, bean name 또는 bean type, 특히 post-processors)에 의해 탐지되는 반면, 일반 DefaultListableBeanFactory는 특정 beans에 대해 무관하다.

For many extended container features, such as annotation processing and AOP proxying, the BeanPostProcessor extension point is essential. If you use only a plain DefaultListableBeanFactory, such post-processors do not get detected and activated by default. This situation could be confusing, because nothing is actually wrong with your bean configuration. Rather, in such a scenario, the container needs to be fully bootstrapped through additional setup.

  • Annotation processing 및 AOP proxying 작업과 같은 많은 확장 컨테이너 기능의 경우 BeanPostProcessor extension point이 필수적이다.
  • 일반 DefaultListableBeanFactory만 사용하는 경우 이러한 post-processors는 기본적으로 탐지 및 활성화되지 않는다.
  • 이 상황은 혼란스러울 수 있다. 왜냐하면 실제로 당신의 bean 구성에 아무런 문제가 없기 때문이다.
  • 오히려 그러한 시나리오에서는 컨테이너를 추가설정을 통해 완전히 bootstrapped할 필요가 있다.

The following table lists features provided by the BeanFactory and ApplicationContext interfaces and implementations.

  • 다음 표에는 BeanFactoryApplicationContext 인터페이스와 구현이 제공하는 기능이 나열되어 있다.

  • Feature Matrix
  • FeatureBeanFactoryApplicationContext
    Bean instantiation/wiringYesYes
    Integrated lifecycle managementNoYes
    Automatic BeanPostProcessor registrationNoYes
    Automatic BeanFactoryPostProcessor registrationNoYes
    Convenient MessageSource access (for internalization)NoYes
    Built-in ApplicationEvent publication mechanismNoYes

To explicitly register a bean post-processor with a DefaultListableBeanFactory, you need to programmatically call addBeanPostProcessor, as the following example shows:

  • DefaultListableBeanFactory에 bean post-processor를 명시적으로 등록하려면 다음 예에서 볼 수 있듯이 addBeanPostProcessor를 프로그래밍 방식으로 호출해야 한다.
1
2
3
4
5
6
7
8
val factory = DefaultListableBeanFactory()
// populate the factory with bean definitions

// now register any needed BeanPostProcessor instances
factory.addBeanPostProcessor(AutowiredAnnotationBeanPostProcessor())
factory.addBeanPostProcessor(MyBeanPostProcessor())

// now start using the factory

To apply a BeanFactoryPostProcessor to a plain DefaultListableBeanFactory, you need to call its postProcessBeanFactory method, as the following example shows:

  • BeanFactoryPostProcessor를 일반 DefaultListableBeanFactory에 적용하려면 다음 예시와 같이 postProcessBeanFactory 메서드를 호출하십시오.
1
2
3
4
5
6
7
8
9
10
val factory = DefaultListableBeanFactory()
val reader = XmlBeanDefinitionReader(factory)
reader.loadBeanDefinitions(FileSystemResource("beans.xml"))

// bring in some property values from a Properties file
val cfg = PropertySourcesPlaceholderConfigurer()
cfg.setLocation(FileSystemResource("jdbc.properties"))

// now actually do the replacement
cfg.postProcessBeanFactory(factory)

In both cases, the explicit registration steps are inconvenient, which is why the various ApplicationContext variants are preferred over a plain DefaultListableBeanFactory in Spring-backed applications, especially when relying on BeanFactoryPostProcessor and BeanPostProcessor instances for extended container functionality in a typical enterprise setup.

  • 두 경우 모두 명시적 등록 단계가 불편하기 때문에 Spring-backed 애플리케이션에서 일반적인 DefaultListableBeanFactory보다 다양한 ApplicationContext 변형이 선호되며, 특히 BeanFactoryPostProcessorBeanPostProcessor 인스턴스에 의존하여 일반적인 엔터프라이즈 환경에서 확장 컨테이너 기능을 수행할 경우 더욱 그러하다.

An AnnotationConfigApplicationContext has all common annotation post-processors registered and may bring in additional processors underneath the covers through configuration annotations, such as @EnableTransactionManagement. At the abstraction level of Spring’s annotation-based configuration model, the notion of bean post-processors becomes a mere internal container detail.

  • AnnotationConfigApplicationContext는 모든 일반 annotation post-processors를 등록하고 @EnableTransactionManagement와 같은 configuration annotations을 통해 커버 아래에 추가 프로세서를 가져올 수 있다.
  • 스프링의 annotation-based configuration 모델의 추상화 수준에서 bean post-processors의 개념은 단순한 내부 container 세부사항이 된다.

References

This post is licensed under CC BY 4.0 by the author.

DER과 JOSE

Kotlin Socket 통신 구현