A Spring IoC container manages one or more beans. These beans are created with the configuration metadata that you supply to the container (for example, in the form of XML <bean/> definitions).

• 사용자가 컨테이너에 제공한 설정 메타 정보에 의해 빈들이 생성되고 컨테이너에 저장된다.

Within the container itself, these bean definitions are represented as BeanDefinition objects, which contain (among other information) the following metadata:

메타데이터의 종류

• A package-qualified class name: typically, the actual implementation class of the bean being defined.
  • 패키지 단위로 분류되어있는 클래스 이름들. 보통은 등록된 빈의 구현체 클래스 이름임.
• Bean behavioral configuration elements, which state how the bean should behave in the container (scope, lifecycle callbacks, and so forth).
• References to other beans that are needed for the bean to do its work. These references are also called collaborators or dependencies.
  • 의존관계에 있는 다른 빈들의 정보
• Other configuration settings to set in the newly created object — for example, the size limit of the pool or the number of connections to use in a bean that manages a connection pool.

connection pool이란?

출처 - https://linked2ev.github.io/spring/2019/08/14/Spring-3-커넥션-풀이란/

https://devbox.tistory.com/entry/JSP-커넥션-풀-1

일전에 JDBC강의에서 DB와 자바코드의 연결 첫번째 단계가 드라이버 객체를 얻어오고, 그 다음이 connection객체를 얻어오는 것이었다. 그런데 이것을 모든 sql문장마다 실행시켜주려면 사용자가 많을경우 시간이 매우 오래걸리기 때문에 따로 Pool이란 공간에 한번에 여러개 만들어놓은 connection인스턴스들을 모아놓고, 필요할때마다 주소 가져가서 쓰고 반환하고 하는 방식에 사용되는 공간을 connection pool이라고 하는 듯 하다.

💡 이펙티즈 자바 p34 item6 ‘불필요한 객체생성을 피하라’에는 다음과같은 내용이 있다.

아주 무거운 객체가 아닌 다음에야 단순히 객체 생성을 피하고자 여러분만의 객체 풀(pool)을 만들지는 말자. 물론 객체 풀을 만드는 게 나은 예가 있긴 하다. 데이터베이스 연결 같은 경우 생성비용이 워낙 비싸니 재사용 하는 편이 낫다.

메타데이터로 만들어지는 대표적인 properties that make up the bean definition

in addition to

bean definitions that contain information on how to create a specific bean, the ApplicationContext implementations also permit the registration of existing objects that are created outside the container (by users).

ApplicationContext같은, 빈들을 어떻게 만들것인지에 대한 정보가 담겨있는 빈 definitions 같은 경우에는(ApplicationContext도 bean definition인가..?) 컨테이너 바깥에서 이미 생성되어있는 객체를 컨테이너에 등록하는 것을 허락할 수 있는 설정도 있다고 한다.

This is done by accessing the ApplicationContext’s BeanFactory through the getBeanFactory() method, which returns the DefaultListableBeanFactory implementation. DefaultListableBeanFactory supports this registration through the registerSingleton(..) and registerBeanDefinition(..) methods. However, typical applications work solely with beans defined through regular bean definition metadata.

DefaultListableBeanFactory 가 컨테이너 바깥에서 이미 생성되어있는 객체를 빈으로 등록하게끔 하는 객체라고 함. 이 객체는 getBeanFactory()메서드로 얻을 수 있다…

물론 일반적인 애플리케이션은 regular한 bean definition metadata들로 동작하긴한다.

그럼 저렇게 바깥에서 얻어와 등록하는건 irregular하다는 것인지..?