서블릿과 JSP
- 서블릿을 발전시킨게 Spring!
- DispatcherServlet = spring
1. 서블릿과 컨트롤러 비교
package com.fastcampus.ch2;
import java.io.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
@WebServlet("/rollDice2")
// 1. @Controller + @RequestMapping 합친거랑 동일한 효과!
public class TwoDiceServlet extends HttpServlet {
// 2. HttpServlet을 상속 받아야함! (java는 단일상속!)
public void service(HttpServletRequest request, HttpServletResponse response) throws IOException {
// 3. service 메소드로 변경! (기존은 main) 고정메소드
int idx1 = (int) (Math.random() * 6) + 1;
int idx2 = (int) (Math.random() * 6) + 2;
response.setContentType("text/html");
response.setCharacterEncoding("utf-8");
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head>");
out.println("</head>");
out.println("<body>");
out.println("<h1>안녕하세요?</h1>");
out.println("</body>");
out.println("</html>");
}
}차이점
- 상속을 안받음
- 매개변수도 필요한것만 받음
- 어노테이션도 나눠서 처리!
4-1. webservlet은 매핑을 클래스 하나 당으로 처리하기 땨문에 매핑 하나 당 클래스를 만들어야 함
4-2. 컨트롤러는 메소드에다가 매핑을 해서 하나의 클래스에 새로운 메소드를 만들기만 하면 가능!
2. 서블릿의 생명주기
package com.fastcampus.ch2;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
public void init() throws ServletException {
// 서블릿 초기화 - 서블릿이 생성 또는 리로딩 때, 단 한번만 수행됨.
System.out.println("[HelloServlet] init()");
}
@Override // 호출될 때 마다 반복적으로 수행됨.
public void service(HttpServletRequest request, HttpServletResponse response) {
// 1. 입력
// 2. 처리
// 3. 출력
System.out.println("[HelloServlet] service()");
}
public void destroy() {
// 뒷 정리 작업 - 서블릿이 메모리상에서 제거(unload)될 때, 단 한번만 수행됨
System.out.println("[HelloServlet] destroy()");
}
}
2. 생명주기 관리
ServletContainer
- 이런 메소드들은 서블릿 컨테이너가 자동으로 호출하며, 서블릿을 만들 때
메소드의 내용만 채워주면 됨.
생명주기
[Servlet Context]
1. 요청 → 서블릿 인스턴스 존재? (children을 보고 확인)
1-1. (Yes) service() 메소드 실행
1-2. (No) 서블릿 클래스 로딩 & 인스턴스 생성 → init() 메소드 실행 후 service() 메소드 제공
2. 프로그램 변경, 웹 App이 종료돼서 Servlet이 메모리에 변경될 때 Destroy() 호출!
[Servlet Context > children]
- 서블릿의 정보가 Map 형태로 구성되어 있음
- Key : 서블릿 이름
- Value : 서블릿
서블릿
- Single Tone 형태 (요청하는 사람마다 동일한 작업을 수행!)
- 사용자마다 다른 일을 할 필요가 없음
- 한 개의 인스턴스만 만들고 재활용함
3. JSP란?
- JSP : Java Server Pages = servlet (변환됨) / html 안에 java 코드가 있는 것
// in jsp 값 출력할 때
<img src='resource/img/dice<%=idx1%>.jpg'><%@ page language="java" contentType="text/html; charset=EUC-KR"
pageEncoding="utf-8"%>
<%@ page import="java.util.Random" %>
<!-- 클래스 영역 -->
<%!
int getRandomInt(int range) {
return new Random().nextInt(range)+1;
}
%>
<!-- 메서드 영역 - service()의 내부 -->
<%
int idx1 = getRandomInt(6);
int idx2 = getRandomInt(6);
%>
<!DOCTYPE html>
<html>
<head>
<meta charset="EUC-KR">
<title>twoDice.jsp</title>
</head>
<body>
<img src='resource/img/dice<%=idx1%>.jpg'>
<img src='resource/img/dice<%=idx2%>.jpg'>
</body>
</html>-> 아래 메서드 영역부분이 다 webServlet의 service 메서드 안에 들어감
<%와<%!의 차이
1.<%: 지역 변수<%!: 인스턴스 변수, 상수 선언 -> 서비스 메서드가 아닌 클래스 안에 들어감
.jsp파일의 경로
: src/main/webApp/ ...
4. JSP의 호출 과정
절차
- *.jsp 요청 → JspServlet
(서블릿 인스턴스 존재?)
1-1. (Yes) 서블릿 인스턴스 _jspService()
1-2. (No) .jsp → servlet으로 변환 & 서블릿 소스파일 컴파일 → 서블릿 클래스 파일 → 인스턴스 생성 _jspInit() (초기화) → 서블릿 인스턴스 _jspService()
-> 처음 호출할 때는 시간 지연이 있음 - 서블릿 인스턴스가 응답! (서비스 메서드가 응답)
- *.jsp 변경시 변환과정 동일하게 진행
특징
- 초기화
- 서블릿 : lazy-init (지연된 초기화)
- Spring : early-init (미리 초기화)
- 동일한 Single Tone 형태
5. JSP의 기본 객체
- 생성없이 사용할 수 있는 객체
request,response,session,pageContext,out
-> jsp가 servlet으로 객체되니까 생성없이 호출할 수 있음 (service 메서드의 로컬 변수 형태로!)
6. 유효 범위(scope)와 속성(attribute)
HTTP 특징
- (stateless) 상태 정보를 저장하지 않는다 <-> stateful : 상태 정보 저장 O
-> 따라서, 4개 저장소 (map형태) 운영 (1) 접근 범위 (2) 생존 기간
4개 저장소 특징
- pageContext
- 목적 : 지역변수, 기본 객체 (request, response, out, session) 저장
- 범위 : login.jsp (해당 페이지 안에서만 접근 가능) => R/W 가능
- 예시 :
${idx1} - 특징
1. EL (${}) 에서는 지역 변수에 직접 접근이 불가능함. EL에서 쓰려면 해당 저장소에 먼저 저장을 해야 함. => 따라서, 같은 페이지 안이지만 읽고 쓰기가 가능하기 위해서 해당 저장소를 이용
2. 요청할 때 마다 새로 초기화
- application (전체)
- 목적 : 공용 저장소
- 범위 : WebApp 전체에서 접근가능한 저장소 (전체 딱 하나!) map 형태로 저장
- 메소드 1) 쓰기(저장) : setAttribute() // key = 속성 (attribute)
2) 읽기(조회) : getAttribute() - 특징
1. 전체 App에서 공용으로 쓰기 때문에, 개별 페이지 속성을 구분하기에는 좋은 저장소가 아님- web app 시작부터 종료까지 context 내부 어디서나 접근 가능
- 모든 클라이언트가 공유!
- context마다 1개
- session (개별 / ★ 가장 편리하지만, 메모리 부담이 큼)
- 목적 : 개별 저장소 (클라이언트 1:1)
- 용도 : id, 장바구니 등 사용자 개별 저장소!
- 특징 1) 사용자마다 하나씩 있는 개별 저장소 * 사용자 수, 최소한의 데이터만 저장!
2) 서버 부담이 제일 큼!
- request 저장소 (★ 가장 부담이 적음 / 요청이 처리되는 동안에만 유지)
- 목적 : 하나의 요청마다 생김
- 특징 : a.jsp 거쳐서 b.jsp에 접근해야 될때도 사용 (forward)
속성 관련 메서드
- setAttribute() : 지정된 값을 지정된 속성 이름(name)으로 저장 (쓰기)
- getAttribute() : 지정된 이름으로 저장된 속성의 값을 반환 (읽기)
- removeAttribute() : 지정된 이름의 속성을 삭제
- getAttributeNames() : 기본 객체에 저장된 모든 속성의 이름을 반환
7. URL 패턴
- webServlet으로 서블릿을 URL에 맵핑할 때 사용!
- loadOnStartup=1 (미리 초기화 / 우선순위)
- servlet : lazy-init (늦은 초기화)
- exact mapping : 정확히 매칭 (
/login/hello.do) - path mapping : 경로 매핑 (
/login/*) - extension mapping : 확장자 매핑 (
*.do) ex) .../hi.do - default mapping : 모든 주소에 매핑됨
servletMappings
[절차]
1. 요청이 들어오면, key값을 확인
2. key값이 존재하면 해당 value가 children(서블릿) key값에 존재하는지 확인
3. value (StandardWrapper) 메모리 값에 따라 서비스를 찾음
ex) /hello, *.jsp = 동적 리소스 (서블릿) / / = 정적 리소스 (default)
=> 요청에 해당하는 서블릿이 없으면 다 dispatcherServlet이 받음!
== 스프링의 경우 jsp, servlet이 없으니까 모~든 요청을 다 dispatcherServlet이 받음!
& dispatcherServlet 내부에 이런 매핑을 다 가지고 있음 (@RequestMapping)
8. EL (Expression Language)
<%=값%>=>${값}- empty는 null / 빈 컬렉션 배열 일때는 true 반환!
9. JSTL (JSP Standard Tag Library)
- <% ~ %> : 이런걸 다 없애려고 나옴 (jstl)
<c:set>,<c:if>,<c:forEach> <c:set>: el값이 지역 변수를 사용하지 못하니까 저장소에 저장하기 위해서 고안
=> scope = "page"
10. Filter
- 공통적인 요청 전처리와 응답 후처리에 사용 ex) 로깅, 인코딩 (변환) 등
- 서블릿은 처리 부분만 담당!
- 필터가 여러 개일 수 있음! filter1 → filter2 -> 서블릿 -> filter2 (후처리) -> filter1
Front-End Developer