13강 - ApplicationContext가 무엇인가요?

# 이번 강의부터 Spring Container 내용

 

 

 

# 복습

- 스프링에서 아파치는 머리에서 지우자. ( 스프링에서 정적자원 요청 안함 -> 모두 자바파일(서블릿) 요청 )

- 무조건 다 톰켓

- Dispatch Servlet 은 주소 분배 하는 애 ( 메모리에 떠있어야 연결가능 (static이 아닌이상))

- static은 main메서드 실행 전부터 메모리에 떠있음(프로그램 끝까지)

- 특정한 타임에 메모리에 떴다가 특정한 시간에 메모리에서 사라지는 애들 = 객체

- 그러므로 static은 객체와 다르다.

 

만약 모든 자바파일이 static으로 되어있으면 여러명이 들어와서 값 바꾸면 충돌 일어남

모든 자바파일(극히 일부 유틸 제외)는 new해주어야한다. -> 그 작업을 스프링(Dispatch Servlet)이 컴포넌트 스캔을 통해서 src 이하 모든 파일을 스캔 후 필요한 (자바)파일을 new 해준다.(IoC) (스프링부트부터 자동으로 패키지 이하 필요한파일로 잡힌다.)

- 필요한 파일 , 불필요한 파일을 어떻게 구분하냐? -> 스프링이 정해둠 (어노테이션으로) 

- @Controller  :  얘네 들은 컨트롤러의 역할을 할거야 -> Dispatch Servlet 니가 스캔할때 다 메모리에 띄워

- @RestController, @Configuration, @Repository, @Service, @Component 등등..

  위 어노테이션 특징 : 들어가보면 다 @Component 어노테이션을 가지고 있다.

- Dispatch Servlet 이 컴포넌트 스캔을 할 때 어노테이션을 찾는다. -> 있는 것을 new하기

- 컴포넌트 스캔으로 IOC하여 메모리에 띄우면 스레드별로 따로 관리 됨.

-   메모리에 띄워=스프링 빈으로 등록

-   애플리케이션 있는 패키지 하위만 스캔

 

- Dispatch Servlet이 필요한 파일 모두 new 한 뒤로 이제 주소 분배 할 수 있다.

 

# Dispatch Servlet의 목적

= 1. 컴포넌트 스캔, 2. 주소 분배

 

 

# new하여 메모리 올리는 곳 = Spring IoC Container

 

 

- 그러나 이 모든 요청하는 애들이 공통적으로 써야하는 것도 있음 ( 계속 new할 필요없이 ) = DB커넥션

- 이런 공통적으로 사용 해야 하는 것들은 Dispatch Servlet 전에 Context Loader Listener를 통해서 미리 메모리에 띄움

- Context Loader Listener 는 root-ApplicationContext 라는 xml파일을 읽는다. -> Context Loader Listener가 스레드로 따로 관리 해야되는 애들 말고 공통으로 관리해야 될 것들을 메모리에 띄워줌 -> IOC container에서 관리해줌

- 실행 순서 1. Context Loader Listener, 2. Dispatch Servlet

 

 

 

매우 중요!!

 

 

 

 

 

 

 

 

ApplicationContext의 종류에는 두가지가 있는데 (root-applicationContext와 servlet-applicationContext) 이다.

a. servlet-applicationContext

servlet-applicationContext는 ViewResolver, Interceptor, MultipartResolver 객체를 생성하고 웹과 관련된 어노테이션 Controller, RestController를 스캔 한다.

============> 해당 파일은 DispatcherServlet에 의해 실행된다. 

 

b. root-applicationContext

root-applicationContext는 해당 어노테이션을 제외한 어노테이션 Service, Repository등을 스캔하고 DB관련 객체를 생성한다. (스캔이란 : 메모리에 로딩한다는 뜻)

============> 해당 파일은 ContextLoaderListener에 의해 실행된다. ContextLoaderListener를 실행해주는 녀석은 web.xml이기 때문에 root-applicationContext는 servlet-applicationContext보다 먼저 로드 된다.

 

당연히 servlet-applicationContext에서는 root-applicationContext가 로드한 객체를 참조할 수 있지만 그 반대는 불가능하다. 생성 시점이 다르기 때문이다.

 

- Context Loader Listener가 띄운 애들은 Dispatch Servlet 이 띄운 애들에게 접근 불가

      - 이유 1. static -> nonstatic 접근불가

      - 이유 2. Dispatch Servlet이 띄운 애들은 늦게 만들어져서

- Dispatch Servlet 가 띄운 애들은 Context Loader Listener 이 띄운 애들에게 접근 불가

      - 이유 1.  nonstatic -> static 접근가능

      - 이유 2. Context Loader Listener가  띄운 애들은 이미 만들어져서

- 그러므로 Dispatch Servlet이 띄운 애들은 DB에 접근 가능

 

 

 

 

 

#Bean Factory (ApplicationContext 안에 있음)

 

필요한 객체를 Bean Factory에 등록할 수 도 있다. 여기에 등록하면 초기에 메모리에 로드되지 않고 필요할 때 getBean()이라는 메소드를 통하여 호출하여 메모리에 로드할 수 있다. 이것 또한 IoC이다. 그리고 필요할 때 DI하여 사용할 수 있다. ApplicationContext와 다른 점은 Bean Factory에 로드되는 객체들은 미리 로드되지 않고 필요할 때 호출하여 로드하기 때문에 lazy-loading이 된다는 점이다.

 

1. class 가 @configuration 어노테이션있을 때 객체 메서드는 @Bean 어노테이션으로 IOC 할 수 있다.

2. 클래스에서 해당 메서드가 필요할 때 메모리에 뜸 ( servlet-applicationContext나 root-applicationContext 처럼 최초에 뜨는게 아님 )

 

필요할 때 호출하여 메모리에 로드

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

https://cafe.naver.com/metacoding/83

https://getinthere.tistory.com/11?category=813090

참고한 자료~!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

본 자료를 참고하였습니다.

 

 

꾸준히 다시보자.

 

1. 220729

2. 220812

3. 220830

4. 220927