[JSP] JSP 동작과 처리 과정

학습 목표

·  JSP 동작과 처리 과정

·  출력 버퍼와 응답

·  웹 어플리케이션 폴더 구성과 URL 매핑

·  웹 어플리케이션 배포

---

JSP 동작과 처리 과정

 

· JSP 페이지에 대한 요청을 WAS가 처리하는 방법

   - JSP에 해당하는 서블릿이 존재하지 않을 경우

   1. JSP 페이지로부터 자바 코드를 생성 (변환(translation) 단계)

   2. 자바 코드를 컴파일해서 서블릿 클래스를 생성 (컴파일 단계)

   3. 서블릿에 클라이언트 요청을 전달

   4. 서블릿이 요청을 처리한 결과를 응답으로 생성

   5. 응답을 웹 브라우저에 전송

   - JSP에 해당하는 서블릿이 존재하는 경우 

   1. 서블릿에 클라이언트 요청을 전달

   2. 서블릿이 요청을 처리한 결과를 응답으로 생성

   3. 응답을 웹 브라우저에 전송

https://velog.io/@jsj3282/JSP-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95

· JSP를 요청하면 JSP를 직접 실행하는 것이 아니라, JSP를 자바 코드로 변환한 뒤 컴파일해서 생성한 서블릿을 실행하는 것

· 톰캣은 work폴더에 JSP를 변환한 자바 소스 코드와 서블릿 클래스를 생성함

· JSP 페이지를 변경하면 이미 서블릿이 생성되어있어도 JSP 페이지로부터 서블릿 클래스를 다시 생성함                                     

 

출력 버퍼와 응답

· JSP 페이지는 응답 결과를 곧바로 웹 브라우저로 전송하지 않고, 

출력 버퍼에 임시로 응답 결과를 저장했다가 한 번에 웹 브라우저에 전송함

https://lunalog.tistory.com/21

· 위 방법의 장점:

   1. 데이터 전송 성능 향상

   - 데이터를 작은 단위로 여러 차례 보내는 것보다, 큰 단위로 한 번에 묶어 보내는 것이 더 높은 성능을 발휘함

   2. JSP 실행 도중 버퍼를 비우고 새로운 내용 전송 가능

   - <jsp:forward> 기능 사용 가능 (하나의 JSP 페이지에서 다른 JSP페이지로 요청 처리를 전달하는 기능)

   - JSP실행 과정에서 에러 발생시, 생성한 내용을 버퍼에서 지우고 에러 화면 출력 가능

   3. 버퍼가 다 차기 전까지 헤더변경 가능

   - HTTP 프로토콜 구조상 응답 상태 코드와 함께 헤더 정보를 가장 먼저 전송해야해서,

     WAS는 처음 버퍼의 내용을 웹 브라우저로 전송하기 전에 헤더 정보를 전송하고,

    첫 번째로 버퍼의 내용을 웹 브라우저에 전송하기 전까지 헤더 정보를 얼마든지 변경 가능

    - 버퍼 내용을 전송한 후에는 응답 헤더 값을 변경해도 웹 브라우저에 전송되지 않고 무시됨

 

· 버퍼의 동작 방식

https://velog.io/@jsj3282/%EC%B6%9C%EB%A0%A5-%EB%B2%84%ED%8D%BC%EC%99%80-%EC%9D%91%EB%8B%B5

 

· page 디렉티브로 buffer 속성을 제공하여, JSP 페이지가 사용할 버퍼 설정 가능

   - JSP 페이지 작성시 buffer 속성을 지정하지 않으면, 최소한 8KB 이상의 크기를 갖는 버퍼로 자동 설정됨

▶ 예시 - JSP 페이지가 사용할 4KB의 크기를 갖는 버퍼 설정

<%@ page buffer = "none"%>

 

· buffer 속성 값을 "none"으로 지정하면 JSP 페이지가 출력하는 내용을 곧바로 웹 브라우저에 전송 -> 제한 발생

   1. <jsp:forward> 기능을 사용할 수 없음

   2. 곧바로 전송되기 때문에 출력한 내용을 취소할 수 없음

▶ 예시 - 버퍼 사용 x

<%@ page buffer = "none"%>

 

· page 디렉티브로 autoFlush 속성을 제공하고, 버퍼가 다 찼을 때 어떻게 처리할지 결정 가능

   - true: 버퍼가 다 차면 버퍼를 플러시하고 계속해서 작업을 진행

   - false: 버퍼가 다 차면 익셉션을 발생시키고 작업을 중지 (JSP Buffer overflow)

· 플러시(flush): 버퍼가 다 찼을 때, 버퍼에 쌓인 데이터를 실제로 전송되어야 할 곳에 전송하고 버퍼를 비우는 것

 

서블릿/JSP 웹 어플리케이션 폴더 구성과 URL 매핑

· 서블릿/JSP 규약은 웹 어플리케이션이 특정 폴더 구조를 따르도록 제한함

   - WEB-INF: 웹 어플리케이션 설정 정보를 담고 있는 web.xml 파일이 위치

   - WEB-INF\classes: 웹 어플리케이션에서 사용하는 클래스 파일이 위치

   - WEB-INF\lib: 웹 어플리케이션에서 사용하는 jar 파일이 위치

   - WEB-INF 폴더와 그 하위 폴더를 제외한 나머지 폴더에는 웹 어플리케이션에서 사용할 JSP, HTML, 이미지 등의 파일이 위치함 

https://velog.io/@jsj3282/웹-어플리케이션-폴더-구성과-URL-매핑

· 톰캣의 webapps 폴더에 하위 폴더는 자동으로 웹 어플리케이션에 포함되고, 이는 URL 경로가 됨

[톰캣]\webapps\[웹경로] -> http://host:port[/웹경로]

· webapps 폴더에는 ROOT라는 특수 폴더가 존재하고, 해당 폴더는 빈 문자열인 ""이다

 

▶ 예시

 

webapps\chap1 -> http:localhost:8080/chap04
webapps\ROOT -> http:localhost:8080

 

· URL의 첫 번째 경로와 일치하는 컨텍스트 경로를 가진 웹 어플리케이션이 존재하지 않으면,

루트 웹 어플리케이션이 요청을 처리함

   - 예: http://localhost:8080/view/loginForm.jsp URL 요청시 webapps\view 폴더가 존재하지 않으면, 

     루트 웹 어플리케이션 폴더인 ROOT를 기준으로 view/loginForm.jsp 파일을 찾음. 

     즉, webapps\ROOT\view\loginForm.jsp 파일을 찾아 실행 

 

· request 기본 객체는 컨텍스트 경로를 제공하는 메서드를 정의함

  request.getContextPath()

 

웹 어플리케이션을 WAS에 배포하기

· 웹 어플리케이션을 WAS에 배포하는 두 가지 방법:

   1. 대상 폴더에 파일을 직접 복사

   - 톰캣의 webapps\chap03과 같은 폴더에 직접 JSP 파일을 저장 (로컬PC일 경우 FTP 이용)

   2. war 파일로 묶어서 배포

   - war(Web Application Archive): 웹 어플리케이션 구성 요소를 하나로 묶어 놓은 파일

   - JDK의 jar 명령어를 cvf 옵션으로 사용하여 war 파일 생성 가능. jar 명령어는 [JDK설치폴더]\bin 폴더에 존재함.

        ◈ c: 새로운 파일 생성

        ◈ v: 세부 정보를 콘솔에 표시

        ◈ f: 생성할 파일의 이름을 지정

   - PATH 환경 변수에 [JDK설치폴더]\bin 폴더를 추가하면, 전체 경로를 입력하지 않고 jar 명령어 실행 가능 

 

▶ 예시 - war 파일 생성

jar cvf chap04.war *

· 옵션 뒤에 "char04.war"는 생성할 파일 이름

· 마지막 "*"는 현재 폴더의 모든 파일과 하위 폴더가 대상임을 의미

· 생성된 war파일을 [톰캣]\webapps 폴더에 복사하면 배포가 완료됨

· war파일을 webapps 폴더에 복사한 뒤 톰캣을 실행하면 chap04 폴더가 생성되고,

이 폴더는 /chap04 컨텍스트를 갖게 됨

 

출처

최범균의 JSP 2.3 웹 프로그래밍: 기초부터 중급까지