[spring] 컨텍스트계층구조_부모_자식_컨텍스트

1.     Spring-bean : 스프링 코어와 함께 의존성 주입 제공 (Core Container)

2.     Spring-context : 스프링 코어, BeanFactory를 확장한 어플리케이션 컨텍스트 구현, 리소스 로드 및 국제화 지원(Core Container)

3.     Spring-core : 다른 스프링 모듈이 사용하는 유틸리티(Core Container)

4.     Spring-expression : EL 확장 Bean속성(배열, 컬렉션 포함).(Core Container)

5.     Spring-aop : 스프링 기능 자체의 aop, Spring ProxyFactoryBean

6.     Spring-jcl : 뭔지 모르지만 다운받아짐

7.    Com.springsource.junit : junit > Java10 문제인지 Maven문제인지 잘 인식이 안되서 시스템 라이브러리르 등록함. 호환되는 junit5버전이 있지만 설명이 많이 없어서 걍 4씀

 

Printer 인터페이스를 구현한 클래스는 얼마든지 만들 수 있다(여러가지 기술로).

 

Printer를 구현한 각자 기능에 충실하게 독립적으로 설계된 POJO 클래스(구현체)를 만들고, 결합도가 낮은 유연한 관계를 가질 수 있도록 인터페이스를 이용해 연결해주는 것이 IOC컨테이너가 사용할 POJO를 준비하는 첫 단계 이다.

 

 

 

GenericApplicationContext가 사용할 메타정보

 

* IOC 컨테이너 계층구조

- 빈을 담아둘 IOC 컨테이너는 애플리케이션마다 하나씩이면 충분하다. 빈의 개수가 많아 설정설정파일이 커지는 것이 문제라면, 파일을 여러 개로 쪼개서 만들어 하나의 어플리케이션 컨텍스트가 여러 개의 설정파일을 사용하게 하면 그만이다.

- 한 개 이상의 IOC 컨테이너를 만들어 두고 사용해야할 경우가 있다.

1) 부모 컨텍스트를 이용한 계층구조 효과

> 모든 어플리케이션 컨텍스트는 부모 어플리케이션 컨텍스트를 가질 수 있다.

> DI를 위해 빈을 찾을 때는 먼저 자신이 관리하는 빈 중에 필요한 빈을 찾아보고, 없으면 부모 컨텍스트에게 빈을 찾아달라고 요청한다. 또 없으면 그 부모에게.. 상속과 개념 비슷.

2) 계층구조를 이용하는 이유

> 기존 설정을 수정하지 않고 사용하지만 일부 빈 구성을 바꾸고 싶은 경우

> 여러 애플리케이션 컨텍스트가 공유하는 설정을 만들기 위해서

3) 계층구조 사용시 주의사항

> AOP처럼 컨텍스트 안의 많은 빈에 일괄적으로 적용되는 기능은 대부분 해당 컨텍스트로 제한된다는 점도 주의.

> 때론 의도적으로 부모 컨텍스트를 무사히고 현재 컨텍스트에서만 원하는 빈을 찾는 기능

 

부모 컨텍스트 그 자체적으로 완전한(누락없는) 빈 설정정보를 갖고 있다.

 

6. parnetContext.xml을 부모컨텍스트로 참조하여 이용되기에 동일한 hello 빈은 childContext에 오버라이드 될 것이다.

8. ref=”printer” 참조하고 있지만 해당 빈이 없다. 하지만 parentContext.xml을 부모 컨텍스트로 이용할 것이다.

 

 

18. StaticApplicationContext는 코드에 의해 설정 메타정보를 등록하는 기능을 제공하는 애플리케이션 컨텍스트다. 테스트용으로 적합함.(스프링의 웹 관련 기능을 공부하거나 학습 테스트로 검증해보고 싶을 때 사용.)

20. StaticApplicationContext의 디폴트 메타정보를 사용해서 싱글톤 빈을 등록해주는 registerSingleton() 메소드 사용.

22, 35. 2개의 bean 등록. IOC컨테이너가 관리하는 빈은 클래스 단위가 아닌 오브젝트 단위. 보통 클래스당 하나의 오브젝트를 만들지만, 경우에 따라서 하나의 클래스를 여러 개의 빈으로 등록한다. 예를 들어 사용할 DB가 여러 개라면 SimpleDriverDataSource 클래스로 된 빈을 여러 개 등록하고 각각 다른 DB 설정을 지정해서 사용할 수 있다.

27. RootBeanDefinition은 가장 기본적인 BeanDefinition 인터페이스의 구현 클래스. 빈에 대한 메타정보를 넣어주고 컨테이너에 등록 가능. ApplicationContext는 BeanDefinition 메타정보를 담은 오브젝트를 사용해 IOC와 DI 작업을 수행한다

39. IOC 컨테이너에서 등록된 빈 설정 메타정보를 가져올 수 있다.

46. printer빈이 hello 빈에게 DI되도록 설정

 

92. GenericXmlApplicationContext는 XML을 사용하는 루트 컨텍스트를 만들때만 사용할 수 있는 편리한 클래스.

95. XmlReader 및 부모를 등록하는 등의 세밀한 설정을 위해서는 GenericApplicationContext를 이용해야한다. 또한 생성자에 parent를 부모 컨택스트를 지정.

100. refresh() : 리더를 사용해서 읽은 경우에는 반드시 호출해야함. GenericXmlApplication Context은 리더를 구현하지 않으므로 생략 가능. 설정 메타정보를 읽고 refresh() 해주면 컨텍스트를 초기화하면서 DI를 진행한다. 이 때 child 컨텍스트에서 필요한 빈이 존재하지 않을 경우 부모 컨텍스트에게 빈 검색을 요청하게 된다.

106. parent.getBean()으로 hello 빈을 요청하면 이 때는 당연히 부모 컨텍스트의 hello 빈을 돌려줄 것이다.

* 계층구조 컨텍스트는 자주 활용되는 방법이지만 부모/자식 컨텍스트에 중복해서 빈이 정의되는 일은 스프링에서 허용하긴 하지만, 가능한한 피해야 하는 것이 옳다. 계층구조 사이의 혼란스러운 빈 정의는 발견하기 힘든 버그를 양산해낼 가능성이 있기 때문.

 

68. GenericApplicationContext

- 가장 일반적인 애플리케이션 컨텍스트. 실전에서 사용될 수 있는 모든 기능을 갖추고 있는 애플리케이션 컨텍스트. 컨테이너의 주요 기능을 DI를 통해 확장할 수 있도록 설계되어 있다.

- StaticApplicationContext와 다르게 XML 파일과 같은 외부 리소스에 있는 빈 설정 메타정보를 리더를 통해 읽어들여서 메타정보로 전환해서 사용.

- 스프링은 메타정보를 애플리케이션 컨텍스트가 사용할 수 있는 BeanDefinition 정보로 변환하는 기능을 가진 BeanDefinitionReader 인터페이스를 구현해서 만들고, 빈 설정정보를 전달하는 대표적인 빈 설정정보 리더는 XmlBeanDefinitionReader다.

66. 스프링의 Resource 타입으로 전달 해도 되지만, 리소스 대신 스트링을 넘기면 기본적으로 클래스패스로 인식. Classpath:나 file:, http: 같은 접두어를 이용해도됨.

67. 스프링은 XML 지옥이란 얘기가 있다. 근거없는 비방이다. XML은 최소한의 꼭 필요한 정보만 사용할 수 있도록 잘 설계된 문서다. 물론 XML을 사용하고 싶지 않다면 XML 파일 없이 스프링 어플리케이션을 만들 수도 있다. GenericApplicationContext는 빈 설정 리더를 여러 개 사용해서 여러 리소스로부터 설정 메타 정보를 읽어 refesh() 메소드를 한번 호출해서 애플리케이션 컨텍스트가 필요한 초기화 작업을 수행하면 된다.

> GenericApplicationContext 를 직접 사용하는 경우?

- 스프링 컨테이너 자체를 확장해서 새로운 프레임워크를 만들거나,

- 스프링을 사용하는 독립형 애플리케이션을 만들 경우

- Junit 역시 GenericApplicationContext를 자동으로 만들어준다.

80. GenericXmlApplicationContext

- GenericApplicationContext를 사용하는 경우 번거롭게 XmlBeanDefinitionReader를 직접 만들지 말고, 이 두 개의 클래스가 결합된 GenericXmlApplicationContext를 사용하면 편리하다.

- GenericXmlApplicationContext는 XmlBeanDefinitionReader를 내장하고 있기 때문에, XML 파일을 읽어들이고 refesh()를 통해 초기화 하는 것까지 한 줄로 끝낼 수 있다.