본문 바로가기

백엔드 잡학사전

[스프링 핵심] 스프링 컨테이너와 스프링 빈

스프링 컨테이너 생성

스프링 컨테이너가 생성되는 과정: 기본적으로 생성자의 꼴로 생성을 한다.

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

 

* ApplicationContext를 스프링 컨테이너이자 인터페이스다. XML로도 만들 수 있지만, 애노테이션 자바로도 만들 수 있음.

앞서서 다룬 AppConfig와 같은. 

 

스프링 컨테이너는 하나만 있는 게 아니라 BeanFactory와 ApplicationContext로 구분하곤 한다. 그런데 BeanFactory를 직접 사용하는 경우는 거의 없으므로 통상 ApplicationContext를 부른다고 생각하면 된다.

 

 

이렇게 만든 빈들을 눈으로 확인해보는 방법은, test에 관련 테스트코드를 만들어주고, AppConfig.class를 불러서 print 해주는 것이다. 참고로 최신 junit5에서는 public 없이도 function을 만들 수 있다.

 

BeanDefinition이라는 게, 스프링에 기본으로 있는 애들은 ROLE_INFRASTRUCTURE, 사용자가 정의한 애들은 ROLE_APPLICATION이다. 이렇게 전체 다 출력하기 보다는 실전에서는 더 작은 범위만을 출력하는 걸 더 필요로 하므로 그걸 좀 더 알아보자.

 

빈 조회하기

 

그냥 메소드들에 익숙해지는 게 최선이다. 별 거 없고, getBean이라는 무적의 메소드를 쓰면 리스트가 촤라락 나온다.

여기서 포인트는 맨 아래, 없는 이름을 조회할 경우처럼 false가 나와야 할 때, junit의 Assertions를 써서 assertThrows와 해당 예외 이름을 던지게끔(뒤에 나오는 게 원인, 앞에 나오는 예외가 결과임) 하는 것이다.

 

만약 똑같은 타입이 두 개 이상이라면? ac.getBeansOfType() 하면 해당 타입의 모든 빈을 보여줌.

만약 그런 상황에서 타입으로 조회를 하게 되면 2개 이상의 Bean을 반환해야 하잖아, 그런데 그렇지 않다. 그냥 오류를 낸다. 반환되는 bean의 개수는 하나여야 하기 때문에. 그렇기 때문에 서로 이름이 다르다는 가정 하에 이름으로 특정하면 문제없이 반환된다.

 

 

자 이제, 좀 더 중요한 개념을 다뤄보자. 바로 스프링 빈 조회에서의 상속관계다.

 

일단 원칙은. 부모 타입으로 조회하면 그 자식들도 함께 모두 조회된다는 것이다.

그러니까 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회한다.

이것도 마찬가지로, 하나의 부모 아래에 있는 같은 타입의 녀석들이 두개 이상이라면 오류를 반환한다.

따라서 이것도 이름으로 특정을 해줘야 한다! 이렇게 빈 조회에 대해서 알아봤다.

 

빈 팩토리와 App Context

 

그렇다면 BeanFactory에 비해 어떤 부가적인 기능이 있길래 Appcontext가 또 필요할까?

 

스프링 빈 설정에 대한 메타정보 BeanDefinition

스프링 컨테이너는 Java인지, XML인지 알아야 할 이유가 없다.

그렇기 때문에 각각의 Bean에 대한 정보가 들어가 있는 BeanDefinition을 만들어 두면, 그걸 토대로 스프링 컨테이너가 스프링 빈을 생성한다. 이 부분은 다음에 필요하면 보충을 하는 걸로.