[요청응답 A-Z] 4. 서버 Runtime 환경

1.정보가 네트워크로 전달 
2. 네트워크에서 서버의 네트워크로 (Netowrk -> AWS) 
3. 서버 Bootstrapping (Tomcat Spring Container)
4. 서버 Runtime 환경 (handler)

 

 

1. Application  - 전체적인 구조 (3단계 복습)

ㄴ java.exe -> catalina.class를 JVM 클래스 메모리에 할당 -> main 실행되며 Tomcat 의 구성품들을 세팅하기 시작함 

HTTP Server (Tomcat 전체)
└── Servlet Container (Tomcat의 서블릿 엔진 부분)
    └── Spring Container (ApplicationContext)

 

✅ server.xml : thread 설정 

thread-1 : HTTP 서버 세팅 (8080 포트 점유) 

thread-2 : Servlet Container 초기화 

• 🧨 Servlet 매 기능마다 n개 등록해야함  + engine 에 너무 의존됨 + Servlet끼리 서로 연결하는 기능 부족 
• 👉 dispatcher servlet과 spring의 탄생 

 

✅ web.xml : application 설정 

new Instance를 할 때 dispatcherServlet 한번 초기화 (sf.mvc.xml) - 모든 요청을 다 여기서 받는다 

init() 을 통해 Controller의 Bean들을 등록 실제 비즈니스 로직을 수행하는 건 application이 담당한다.  

 

[작동순서]

 

• 클라이언트 요청 → HTTP Server가 받음
• HTTP Server → Servlet Container로 전달
• Servlet Container → DispatcherServlet(Spring의 프론트 컨트롤러) 호출
• DispatcherServlet → Spring Container에서 적절한 Controller Bean을 찾아 실행

 

Application Contexxt (Spring container) 의 부모 자식 관계의 순서를 앞 뒤로 나열함

 

자식은 부모의 것을 사용할 수 있다.

즉, 런타임 시 MVC 영역에 도달한 스레드는 Bean 에 등록된 @Service, @Repository 등의 빈을 사용할 수 있다. 

 

🌐 Bean의 등록

• xml <bean> 방식이던 @ComponentScan 방식이던 ▶  Bean으로 등록할 클래스를 스캔함 
• 이때까진 그저 "클래스" 의 형태
  • 🎇 new Instance 로 실행 준비상태인 인스턴스로 만들어주어야 
• Beans 의 의존성 생성과 연결이 거의 동시에 일어남 (생성자 주입 방식의 의존성 주입을 추천하는 이유임)

 

2. Application runtime - view handler 자세히 

1) MVC 패턴

• observing도 하지 않는다면? "MVP 패턴"
• ajax 만 호출한다면 "MVVM패턴" 

 

 

2) view handler

• 반환된 객체를 본 dispatcherServlet -> " 이 형태는 어떤 view handler가 좋을까?"
• 가장 먼저 Tiles handler를 찾아가 처리 (현 프로젝트)
• 이후 처리할 수 있는 handler가 modelandview 객체 (=응답 객체)를 가져다 처리함 
  • Restcontroller에서 ResponseEntity로 응답 객체를 주는 경우엔 resolver가 없음, converter 거치고 그대로 반환
• JSP도 하나의 servlet. model 에 있는 데이터를 servletrequestattribute 에 담아서 jsp servlet 에 담아줌 -> 이후 view 로 반환 

 

3) 전체적인 구조 

• ServletFilter (servlet 진입전)과 Interceptor (servlet 진입 후)

🤔 Spring Security 로직을 보면, xml에 수 많은 Servlet Filter 들이 존재한다. 왜 Servlet Filter를 사용한 것일까? 

 

1) Servlet Filter 활용 예시

• 모든 요청(정적 리소스 포함) 공통 처리
  예: CORS 헤더 추가, 모든 요청에 대한 로깅, XSS 방어용 Request 래핑
• Spring 컨텍스트 진입 전 단계
  예: JWT 토큰 검증 → 유효하지 않으면 바로 HttpServletResponse.sendError(401) 처리
• 서블릿 컨테이너 레벨 설정
  예: URL 패턴( /api/* ) 단위로 필터 체인 순서를 세밀하게 조정

2) Interceptor 활용 예시

• Spring MVC 핸들러(Controller) 호출 전·후
  예: 특정 컨트롤러 메서드에 대해, @AuthRequired 애노테이션이 있으면 권한 체크
• 모델(ModelAndView) 처리, 뷰 이름을 가로채거나 추가 정보 주입
• 핸들러 매핑 이후이므로, 어떤 컨트롤러가 호출될지 알고 처리 가능

 

 

3. 최종 정리 (Spring Framework 기준) 

OS가 JVM Tomcat 프로세스를 실행함

 

포트 번호 : 통신할 수 있는 프로그램 (여기서는 톰캣 WAS 키고 대기) 

 

Servlet Container 세팅 자세히

init()을 통해 초기화 

sf.mv.xml은 presnetation layer 빈을 초기화 

mvc.xml은 view 를 초기화 

 

런타임 요청 받는 순서

 

doService() 를 통해 요청 수행 (Boot/Framwork 같음)

HttpServer 에서 요청을 받아온 Thread는 Threadpool에 Thread를 할당하고 Thread를 종료시킨다 -> accept() 소켓 연결 상태 

JSP 도 Servlet의 일종

 

1. JAR 실행 → JVM 시작

2. 웹 애플리케이션 초기화 시작
   ↓
3-A. Root ApplicationContext 생성 ★
   - ContextLoaderListener가 담당
   - contextConfigLocation 파라미터로 설정 파일 지정
   - 주로 root-context.xml 또는 RootConfig.class 사용
   ↓
4-A. Root Context에서 빈 스캔 및 등록
   - @Service, @Repository, @Component (비즈니스 로직)
   - DataSource, TransactionManager 등 인프라 빈
   - 보통 "com.example.service", "com.example.repository" 패키지 스캔
   ↓
5-A. Root Context 빈 생성 완료
   - 서비스, 리포지토리 빈들이 모두 생성됨
   ↓
3-B. Web ApplicationContext 생성 ★
   - DispatcherServlet 초기화 시 생성
   - Root Context를 부모로 설정
   - 주로 servlet-context.xml 또는 WebConfig.class 사용
   ↓
4-B. Web Context에서 빈 스캔 및 등록
   - @Controller, @RestController (웹 계층)
   - ViewResolver, HandlerMapping 등 웹 관련 빈
   - 보통 "com.example.controller" 패키지 스캔
   ↓
5-B. Web Context 빈 생성 완료
   - 컨트롤러 빈들이 생성됨
   - 이때 서비스 의존성은 부모(Root Context)에서 주입받음
   ↓
6. DispatcherServlet 초기화 완료

7. 웹 서버 시작

8. 애플리케이션 Ready

 

4. 추가 정보 

✅ Framework와 Boot의 차이 

• 서버 부팅과정만 다를 뿐 Runtime 영역 (호출 프로세스)는 동일
• 즉, main을 어떻게 호출하느냐 차이 

 

✅ 언제 Framework가 강점일까 

• GlobalTransaction -> "EJB"
• 제품이 요구하는 모든 조건을 XML 파일에 정리 
• 💦 너무 복잡한데....? 

 

✨POJO의 등장

• 순수한 자바 언어를 사용하여 '선언적' 으로 트랜잭션을 관리할 수 있다! = Spring