1. IoC 컨테이너 : 빈 팩토리와 애플리케이션 컨텍스트

스프링 애플리케이션에서는 오브젝트의 생성과 관계설정, 사용, 제거 등의 작업을 애플리케이션 코드 대신 독립적인 컨테이너가 담당한다.
이를 컨테이너가 코드 대신 오브젝트 제어권을 갖고있다고 해서 IoC 라고 부른다. 그래서 스프링 컨테이너를 IoC 컨테이너 라고도 한다.
스프링에선 IoC를 담당하는 컨테이너를 빈 팩토리 또는 애플리케이션 컨텍스트라고 부르기도 한다.
오브젝트의 생성과 오브젝트 사이의 런타임 관계를 설정하는 DI 관점으로 볼 때는 컨테이너를 빈 팩토리라고 한다.
그런데 스프링 컨테이너는 단순한 DI 작업보다 더 많은 일을 한다. DI를 위한 빈 팩토리에 엔터프라이즈 애플리케이션을 개발하는 데 필요한 여러 가지 컨테이너 기능을 추가한 것을 애플리케이션 컨텍스트라고 부른다.

❗ApplicationContext는 beacFactory interface를 상속받고 있지만, 위임하는 것 외에 다른 로직은 구현하지 않는다.

2. Web ApplicationContext

스프링 애플리케이션에서 가장 많이 사용되는 ApplicationContext는 바로 WebApplicationContext 이다. WebApplicationContext는 ApplicationContext를 확장한 인터페이스이므로 정확히는 WebApplicationContext를 구현한 클래스를 사용하는 셈이다.
웹 애플리케이션에서 만들어지는 IoC 컨테이너는 WebApplicationContext 인터페이스를 구현한 것임을 기억해두자.
WebApplicationContext의 특징은 자신이 만들어지고 동작하는 환경인 웹 모듈에 대한 정보에 접근할 수 있다는 점이다. 이를 이용해 웹 환경으로부터 필요한 정보를 가져오거나, 웹 환경에 스프링 컨테이너 자신을 노출할 수 있다. 컨테이너가 웹 환경에 노출되면 같은 웹 모듈이 들어 있는 스프링 빈이 아닌 일반 오브젝트와 연동될 수 있다.

웹 애플리케이션 레벨에 등록되는 컨테이너는 보통 루트 웹 애플리케이션 컨텍스트라고 불린다.
루트 웹 애플리케이션 컨텍스트는 서블릿 레벨에 등록되는 컨테이너들의 부모 컨테이너가 되고, 일반적으로 전체 계층구조 내에서 가장 최상단에 위치한 루트 컨텍스트가 되기 때문이다.
웹 애플리케이션에는 하나 이상의 스프링 애플리케이션의 프론트 컨트롤러 역할을 하는 서블릿이 등록될 수 있다(디스패쳐 서블릿은 프론트 컨트롤러 패턴으로 구현되었음)
등록된 서블릿에는 각각 독립적으로 애플리케이션 컨텍스트가 만들어진다. 이런 경우 각 서블릿이 공유하게 되는 공통적인 빈들이 생길 수 있다.
공통적으로 사용하는 빈을 루트 웹 애플리케이션 레벨의 컨텍스트에 등록하면 공통되는 빈들이 서블릿별로 중복돼서 생성되는 것을 방지할 수 있다.
하지만 하나의 서블릿이 모든 애플리케이션 요청을 처리하는 프론트 컨트롤러 패턴으로 구현되었기 때문에 여러개의 서블릿 컨테이너를 생성하는 것은 드물다

❗여러개의 자식 컨테이너를 생성하는 것이 아닌데 계층 구조를 사용하는 이유는?

그 이유는 전체 애플리케이션에서 웹 기술에 의존적인 부분과 그렇지 않은 부분을 구분하기 위해서이다. 스프링을 이용하는 웹 애플리케이션이라고 해서

반드시 스프링 웹 서블릿 만들 필요는 없다. 스프링 기술을 사용하고 스프링 빈으로 만들지만 웹을 담당하는 프레젠테이션 계층은 스프링 외의 기술을 사용하는 경우도 종종 있기 때문이다.

모든 애플리케이션 컨텍스트는 부모 애플리케이션 컨텍스트를 가질 수 있다.
계층구조 안의 모든 컨텍스트는 각자 독립적인 설정정보를 이용해 빈 오젝트를 만들고 관리한다.
각자 독립적으로 자신이 관리하는 빈을 갖고 있긴 하지만 DI를 위해 빈을 찾을 떄는 부모 애플리케이션의 빈까지 모두 검색한다.
먼저 자신이 관리하는 빈 중에서 필요한 빈을 찾아보고, 없으면 부모 컨텍스트에게 빈을 찾아달라고 요청한다. (빈을 찾지 못할 경우 계층구조를 따라서 가장위에 존재하는 루트 컽넥스트까지 요청이 전달 됨)
자신과 부모 컨텍스트에 동일한 빈이 존재한다면, 자신이 갖고있는 빈이 우선시 된다. (빈 검색 순서는 자신이 먼저이고, 그 다음 직계 부모의 순서이다.)

❗중요한 건 자신의 부모 컨텍스트에게만 빈을 요청하고, 자식 컨텍스트에게는 요청하지 않는 점이다. 그런 이유로 같은 레벨에 있는 형제 컨텍스트의 빈도 찾을 수 없다.

WAS 가 구동될 때 Web.xml 의 설정 정보를 리딩한다.
리딩되면서 SpringContextLoader가 Web.Xml의 contextConfigLocation 의 파일경로를 스캔하고 root-context로 생성한다.

❗dispatcher-servlet context 안에서도 contextConfigLocation 을 생성하고 있는데 context-param 안의 contextConfigLocation가 root-context 인 이유는?

자세하진 않지만 .. context-param 과 init-param 의 차이는 전역변수, 지역변수의 개념과 비슷하다. context-param 안에서 생성된 빈은 모든 서블릿에서 사용할 수 있다.

init-param으로 생성된 빈들은 해당 서블릿 안에서만 참조가 가능하다. 이런 이유 때문에 context-param 안에 생성된 contextConfigLocation를 root-context 로 인식하는게 아닐까 싶다.