1. JSP 개요
※ CGI(Common Gateway Interface)
웹상에서 서버와 상호연동하기 위한 일종의 규약으로 웹에서 사용자가 어떤 요청을 웹 서버에게 하면 웹서버는 하나의 프로
세스를 실행시킨다. 이 프로세스에 사용자가 어떤 요청을 했는지에 대한 정보가 넘어가고 프로세스가 정보를 가공한 뒤, 결
과를 웹서버에게 넘겨주면 웹서버는 이를 다시 사용자의 브라우저로 보낸다. 즉, 웹서버가 어플리케이션 프로그램을 직접
호출하여 그 처리 결과를 클라이언트에게 전송하는 구조
※ 서블릿
Server + Applet 확장한 CGI 방식으로 SUN사에서 내놓은 기술로서 Server Side Applet 이라고 이해할 수 있다. 즉 서버에
서 돌아가는 Applet이라는 뜻인데, 애플릿을 떠올리면 금방 이핼 수 있을 것이다. 사실 Servlet은 애플릿에서만 쓰이도록
디자인 된 것은 아니다. HTTP뿐만 아니라 TCP를 기반으로 하는 여러 가지 프로토콜에 사용할 수 있지만 현재의 가장 큰
용도는 CGI의 대체물이라고 해도 과언은 아니다. Servlet의 패키지중에는 HTTP에 대한 지원을 목적으로 포함된 패키지가
있으니 말이다.
※ 서블릿 컨테이너 (서블릿 엔진)
클라이언트 요청에 서블릿 인스턴스를 생성하거나 해당 인스턴스에 대한 요청을 처리할 스레드를 생성하고 관리하는
서버측 자바 프로그램
※ JSP 컨테이너
JSP 파일에 대한 요청이 들어올 때 해당 파일에 대한 자바 원시 코드를 생성, 컴파일하고 이를 통하여 자바의 객체(
서블릿 인스턴스)를 생성하는 일을 하는 자바 프로그램
※ 페이지 컴파일 서블릿(톰캣 경우는 web.xml에 org.apache.jasper.servlet.JspServlet 이 있다.)
서블릿 컨테이너로부터 요청시에 페이지 컴파일을 담당하는 특별한 서블릿 이라고 할 수 있다.
(페이지만 담당하여 처리하는 서블릿)
웹 서버로부터 요청을 넘겨받은 서블릿 컨테이너는 요청에 사용된 URL에 대하여 미리 설정된 특별한 서블릿을 통해 서블릿이나 JSP 파일을 실행
※ 서블릿 동작 원리
㉮ HTTP servlet이나 다른 종류의 서블릿을 생성하기 위해서는 서블릿 API를 이용해야함.
㉯ 서블릿은 두 패키지인 javax.servlet 과 javax.servlet.http의 클래스와 인터페이스를 이용함.
㉠ javax.servlet 패키지
- 프로토콜에 독립적인 서블릿을 만들기 위해 클래스를 제공
- 프로토콜에 독립적인 서블릿은 javax.servlet.GenericServlet의 서브 클래스
- Generic 서블릿은 요청을 처리하기 위해 자신의 service() 메소드를 오버라이드 해야함.
- service() 메소드는 두 개의 파라미터(request 객체와 response 객체)를 받아들인다.
request 객체는 클라이언트의 요청을 처리하고 , response 객체는 클라이언트의 요청의 처리 결과를
클라이언트에 반환하기 위해 사용
㉡ javax.servlet.http 패키지
HTTP 프로토콜의 고유한 기능(GET, POST 등)을 제공하는 서블릿을 만드는 클래스를 제공
HTTP 서블릿은 HttpServlet의 서브 클래스
- Http 서블릿은 일반적으로 service() 메소드를 오버라이드하지 않는다.
대신 get 요청을 다루기 위해 doGet()을 오버라이드하며, Post 요청을 다루기 위해 doPost()를 오버라이드 한다.
㉰ javax.servlet 패키지 안에는 ServletRequest와 ServletResponse 클래스 Generic 서블릿의 request(요청)와 response
(응답)에 대한 접근을 제공하는 반면에 javax.servlet.http 패키지 안에는 있는 HttpServletRequest와 HttpServlet와 HttpServletResponse는 HTTP 요청과 응답 에 대한 기능을 제공
㉱ 서블릿 파일은 main() 함수를 가지고 있지 않다.
CGI 프로그램의 경우 각 요청(Request)을 처리할 때마다 Process 를 구동해야 하나,
서블릿의 경우 Thread 가 생성되어 서비스를 한다.
CGI 프로그램보다 서블릿이 컴퓨터 리소스를 사용하는 측면이나 성능(Performance)측면에서 유리하다.
서블릿의 경우 Java 안에 HTML 코드를 넣기 때문에 비즈니스 로직과 프레젠테이션 로직이
분리되지 않아서 유지보수나 개발의 복잡성이 존재한다.
JSP의 경우 HTML 코드 안에 Scriptlet 을 넣기 때문에
비즈니스 로직과 프레젠테이션 로직이 분리되어 프로그램의 개발 및 유지보수가 용이해졌다.
클라이언트 요청을 서블릿이 해석하여 다른 URL로 보내야 한다고 판단할 경우 HTTPResponse에 301값과
location헤더에 새로운 URL 값을 포함시켜 클라이언트 브라우저가 다시 새로운 URL을 요청하는
Redirect 방식과 클라이언트 요청을 서블릿이 처리할 때 서버상의 다른 컴포넌트에게 바로 제어권을 넘겨주는
Forward 방식이 있다.
2. 기본 문법
지시어 엘리먼트
page : 스크립트 언어, 버퍼 사이즈와 같은 페이지 정보를 나타낸다.
include : 변환 단계에서 다른 파일을 포함시키는 명령이다.
taglib : jsp에서 사용하는 커스텀 액션을 포함하는 태그 라이브러리를 정의한다.
ex) <%@ page 속성1="..", 속성2=".." ...%>
스크립트 엘리먼트
<%..........%> 스크립릿이라고 하며 JSP 코드를 삽입할 때 사용된다.
<%=.......%> 표현식이라고 하며 결과값을 html에 그대로 반영한다.
<%!.........%> 선언문이라고 하며 jsp 페이지 구현 클래스에서 인스턴스 변수 및 메소드를 선언할 때 사용
3. 생명주기
Servlet
서블릿의 생명 주기(life cycle) : service() 부문에 요청에 대하여 반복됩니다.
init() -> service() -> destroy()
└─────┘
init : 초기화 및 자원 할당
service : 서비스 제공
destroy : 자원 해제 및 소멸
웹 컨테이너는 서블릿 클래스를 로딩하며, 서블릿의 생성과 소멸의 제어를 수행한다.
웹 컨테이너는 서블릿 인스턴스를 생성한 후, init() 메소드를 호출하여 서블릿을 초기화한다.
이 메소드는 해당 서블릿 인스턴스에 대하여 단 1번만 호출된다.
클라이언트 요청을 받으면 웹 컨테이너는 새로운 쓰레드를 만들거나 쓰레드 풀에서 1개 가지고 와서
서블릿의 service() 메소드를 호출한다. 즉, 클라이언트 요청마다 유일한 쓰레드가 할당된다.
getServletConfig() 메소드를 이용하여 ServletConfig 객체의 참조를 받을 수 있다.
초기화 파라미터 값을 가져오기 위해서는 getinitParameter() 메소드를 이용한다.
컨테이너는 서블릿마다 1개씩 ServletConfig 객체를 생성하며 DD내 있는 초기화 파라미터를 읽어 ServletConfig로 넘겨준다.
컨테이너는 서블릿이 재배포되거나 DD가 수정되는 경우에 초기화 파라미터를 다시 읽어 ServletConfig를 갱신한다.
최초 요청시 Servlet를 구현한 특정 서블릿은 기본 생성자를 이용하여 컨테이너가 서블릿을 생성하여,
init을 호출하여 ServletConfig를 넘겨주어 초기화 파라미터 값을 넘겨줍니다.
(참고로, 초기화 파라미터 값은 DD(Deploy Descriptor)인 web.xml에서 정의된 servlet의 파라미터값을 의미)
또한, 후에 service중 또는 destory등에서 servlet에 정의된 getServletConfig()를 통하여, ServletConfig를 참고할 수 있습니다.
JSP
JSP -> Servlet 변환 -> CLASS 컴파일
1. JSP page의 서블릿 인스턴스가 없을 경우
a. JSP page의 서블릿 class를 로딩
b. 서블릿 클래스의 인스턴스 생성
c. jspInit() 호출하여 서블릿 인스턴스 초기화
2. _jspService() 호출하여 request/response 객체를 파라미터로 넘김
3. 컨테이너 해제등의 이유로 JSP page의 서블릿을 제거할 때 jspDestroy() 호출
JSP의 생명 주기
jspInit() -> _jspService() -> jspDestroy()
└──────┘
웹 컨테이너는 JSP 파일을 서블릿으로 만들기 위한 JAVA 소스파일로 변환한다.
JSP 문법 오류가 있으면 이 시점에서 발생한다.
웹 컨테이너는 JAVA 파일을 컴파일하여 .class 파일로 만든 후 메모리로 로딩한다.
JSP 파일의 배포 후, 서블릿 변환과 컴파일은 1번만 발생한다.
웹 컨테이너가 서블릿을 인스턴스화하면 init() 메소드에서 jsplnit()이 호출되고
요청이 들어올 때마다 새로운 쓰레드를 만들어 개발자가 적절히 재정의한 _jspService() 메소드를 실행한다.
JSP는 Servlet 인터페이스를 확장한 JspPage 인터페이스, 다시 이를 확장한 HttpJspPage 인터페이스를 구현한 서블릿이라 생각하면 됩니다.
(Servlet -> JspPage -> HttpJspPage -> 특정JSP)
Servlet의 init, service, destory를 확장한 jspInit, _jspService, jspDestroy라는 메소드를 가지고 있으며, 생명주기(life cycle)은 서블릿과 유사합니다.
4. 내장 객체
3.1. jsp와 서블릿 내장객체의 비교
|
jsp |
서블릿에서의 클래스 |
|
request |
javax.servlet.http.HttpServletRequset |
|
response |
javax.servlet.http.HttpServletResponse |
|
pageContext |
javax.servlet.jsp.PageContext |
|
session |
javax.servlet.http.HttpSession |
|
application |
javax.servlet.ServletContext |
|
out |
javax.servlet.jsp.JspWriter |
|
config |
javax.servlet.ServletConfig |
|
page |
java.lang.Object |
|
exception |
java.lang.Thowable |
3.2. Request 객체
요청 매개변수 및 속성, 헤더와 같은 정보에 접근할 수 있는 메소드를 제공한다.
서블릿의 Request 객체와 같이 웹 브라우저에서 서버쪽으로 데이터를 전달되게 할 수 있는 객체이다.
3.2.1. 폼에 정의된 값을 받아 올 수 있는 메소드
|
getParameter(name) |
매개변수 name의 값을 알아낸다. |
|
getParameterValue(name) |
매개변수 name의 값을 모두 알아낸다. |
|
getParameterNames() |
폼에 있는 모든 매개변수의 이름을 알아낸다. |
3.2.2. 클라이언트의 정보를 알아내기 위한 메소드
|
getMethod() |
요청방식, 즉 get방식인지 post 방식인지를 알아낸다. |
|
getRequestURL() |
요청 파일의 경로를 알아낸다. |
|
getQueryString() |
URL와 함께 전달되는 입력정보를 나타낸다. |
|
getRemoteHost() |
클라이언트의 호스트 이름을 알아낸다. |
|
getRemoteAddr() |
클라이언트의 주소를 알아낸다. |
|
getRemoteUser() |
이용자의 아이디를 알아낸다(기본 인증 사용시). |
|
getProtocol() |
사용중인 프로토콜을 알아낸다. |
|
getServerName() |
서버의 도메인 네임을 알아낸다. |
|
getServerPort() |
서버의 주소를 알아낸다. |
|
getHeader(name) |
name에 해당하는 헤더 항목의 값을 알아낸다. |
3.3. Response 객체
현재의 웹 서버에서의 클라이언트의 웹 브라우저에게 응답 메시지를 표시할 수 있는 객체로서 헤더 셋팅 및 코드 상태, 쿠키 등의 정보를 가지고 있다.
3.3.1. 주요 메소드
|
setContentType() |
출력 문서의 content-type을 설정한다. |
|
getCharacterEncoding() |
문자의 인코딩 설정 정보를 알아낸다. |
|
setHeader(name, value) |
응답 헤더를 설정한다. |
|
sendRedirect(url) |
지정한 문서로 자동으로 이동한다. |
3.4. Out 객체
주 용도는 print()와 println()메소드를 사용함으로써 응답 html파일에 텍스트를 추가할 수 있다.
즉, 웹 브라우저에 표시될 내용에 관한 출력 스트림이라 할 수 있다.
3.4.1. 주요 메소드
|
isAutoFlush() |
출력 버퍼가 가득 차면 자동으로 처리하는지를 지정한다. |
|
getBufferSize() |
버퍼의 크기를 반환한다. |
|
getRemaining() |
버퍼의 남은 크기를 알아낸다. |
|
clearBuffer () |
버퍼를 비운다. |
|
println(string) |
string을 출력한다. |
|
flush() |
버퍼의 내용을 처리한다. |
|
close() |
버퍼를 닫는다. |
3.5. Application 객체
jsp 파일을 포함하고 있는 웹 어플리케이션에 대한 정보를 가지고 있다.
예를 들면 모든 사용자들에 대한 데이터베이스 연결 및 공유와 같은 다수의 접근 요청에 대한 각각 서로 다른 객체의 참조를 유지할 수 있다.
3.5.1. 주요 메소드
|
getServerInfo() |
jsp 컨테이너의 정보를 반환한다. |
|
getMimeType() |
현재의 content-type을 반환한다. |
|
getRealPath(url) |
지정된 URL의 실제 경로를 반환한다. |
|
log(message) |
message 내용을 파일에 입력한다. |
3.6. Session 객체
서버가 관리하는 클라이언트의 세션 데이터에 사용자가 접근할 수 있도록 해준다. 일반적으로 jsp가 액션 엘리먼트를 이용하여 세션 데이터에 접근할 수 있으므로 Session 객체에 직접 접근할 필요는 없다.
3.6.1. 주요 메소드
|
getId() |
Session의 ID를 반환한다. |
|
getCreateTime() |
Session이 만들어진 시간을 반환한다. |
|
getLastAccessedTime() |
해당 session으로 최근의 요청 시간을 반환한다. |
|
getMaxlanctiveInterval(s) |
Session이 유지될 수 있는 최대시간을 초 단위로 세팅한다. |
|
isNew() |
Session에 id가 없으면(새 것이면) true를 반환한다. |
|
invalidate() |
현재의 Session을 버린다. |
|
getAttribute(name) |
Name 값에 대한 세팅된 값을 반환한다. |
|
setAttribute(name, value) |
Name 값에 값을 저정한다. |
3.6.2. 세션(Session)과 쿠키(Cookie)
세션(Session)이란 말하자면 접속에 대한 지속적인 상태라고 할 수 있다.
예를 들자면 어떤 사람이 웹 사이트에 접속했다고 가정하면,
이 웹 사이트에는 카운터가 있는데 들어온 개개인에 대한 카운터라고 하자.
만약 이 사람이 지난번까지 3번 접속했다면 이번에 접속하면 4번째가 될 것이다.
하지만 갑자기 접속을 끝내고 다시 접속한다면 이것을 5번째로 처리할까? 아니다.
접속한지 얼마 안 되어 연결이 끊어졌다가 다시 접속이 되었으므로 이 웹 사이트와 사용자 간에는 어떠한 연결이 이루어져 있다. 때문에 이번에도 4번째 접속으로 처리될 것이다.
즉, 접속시 어떠한 연결객체가 생성되어 일정 시간 유지되는 동안은 항상 연결된 상태라고 할 수 있다.
쿠키는 클라이언트 쪽에 이런 정보를 저정하는 것이라면 세션은 서버 쪽에 저장하는 것이다.
쿠키보다는 세션을 많이 이용하는 것은 바로 이러한 이유 때문에 세션 쪽이 보안성이 좋다는 점 때문이다.
쿠키(Cookie)는 웹 사이트가 클라이언트의 하드디스크에 입력하는 특별한 테스트 파일로,
이것은 후에 그 사용자에 관하여 무엇인가를 기억할 수 있도록 하기 위한 것이다.
일반적으로, 쿠키는 특정한 사이트에 대한 그 사용자의 취향을 기록한다.
웹의 프로토콜인 http를 사용하면, 웹 페이지에 대한 각각의 요구는 다른 요구들과 상관 관계없이 모두 독립적이다.
그렇기 때문에 웹 서버는 그 사용자에게 이전에 어떠한 페이지가 보내어졌는지에 관한 아무런 기록도 가지고 있지 않으며, 심지어 그 사용자가 이전에 방문했었는지 조자 알기 어렵다.
쿠키는 웹 서버에게 사용자에 관한 파일을 사용자 컴퓨터에 저장하도록 허용하는 장치이다.
쿠키 파일은 대개 자신이 사용하는 브라우저 디렉토리의 하부에 저장된다.
쿠키는 클라이언트에 물리적으로 텍스트로 저장되므로 보안에 대단히 취약하다는 단점을 가지고 있다.
3.7. 기타 객체
page, pageContext, config, exception 객체가 있다.
3.7.1. page 객체
jsp가 실행중인 인스턴스를 가리킨다. 여기에서 getServlet Info() 메소드가 사용된다. config 객체는 jsp의 초기 환경설정 데이터를 정한다.
pageContext 객체는 모든 내장객체를 프로그램에서 접근 가능하도록 하는 메소드를 포함하고 있다.
3.7.1.1 주요 메소드
|
getRequest() |
request 객체를 반환한다. |
|
getResponse() |
response 객체를 반환한다. |
|
getOut() |
out 객체를 반환한다. |
|
getSession() |
session 객체를 반환한다. |
|
getServletContext() |
application 객체를 반환한다. |
|
getPage() |
page 객체를 반환한다. |
|
getServletConfig() |
config 객체를 반환한다. |
|
getException() |
exception 객체를 반환한다. |
3.7.2. cofig 객체
초기 환경설정에 대한 정보를 저장하고 있다. 설정방법은 jsp 컨테이너마다 차이가 있다.
3.7.2.1. 주요 메소드
|
getInitParameterNames() |
초기 환경설정 데이터의 이름을 모두 알아낸다. |
|
getInitParameter(name) |
name에 해당하는 초기 환경설정 데이터의 값을 알아낸다. |
3.7.3. exception 객체
page 속성인 isErrorPage가 true일 때만 생성되는 객체로서 예외 상항에 대한 정보를 가지고 있다.
3.7.3.1. 주요 메소드
|
getMessage() |
예외 상황의 메시지를 가져온다. |
|
printStackTrace(out) |
예외의 발생 경로를 출력한다. |
|
toString() |
예외가 발생한 클래스 이름과 메시지를 가져온다. |
5. 속성 범위
page
한 번의 웹 브라우저의 요청에 대해 하나의 JSP 페이지가 호출된다.
웹 브라우저의 요청이 들어오면 단 한 개의 페이지만 대응된다.
하나의 페이지 내에서만 공유한다.
pageContext 내부 겍체를 사용
request
한 번의 웹 브라우저의 요청에 대해 같은 요청을 공유하는 페이지가 대응
객체를 하나 또는 두 개의 페이지 내에서 공유할 수 있다.
include 액션 태그, forward 액션 태그를 사용하면 request 내부 객체를 공유하게 되서 같은 request 영역이 된다.
주로 페이지 모듈화에 사용
request 내부 객체 사용
session
하나의 웹 브라우저당 1개의 session 겍체가 생성
같은 웹 브라우저 내에서 요청되는 페이지들은 같은 객체를 공유하게 된다.
주로 회원인증에 사용
session 내부 객체를 사용
application
하나의 웹 어플리케이션당 1개의 application 객체가 생성
같은 웹 어플리케이션에 요청되는 페이지들은 같은 객체를 공유한다.
application 내부 객체를 사용
6. 상태 유지
HttpSession을 이용하면 HTTP 프로토콜이 stateless 특징을 가짐에도 불구하고 한 클라이언트의 전체 세션 간 정보를 이용할 수 있다.
상태유지 방법으로 데이터베이스나 상태유지 세션빈을 사용하더라도, HttpSession 객체를 사용해야 한다.
이는 특정 사용자와 특정 DB 키 또는 세션빈 아이디를 매칭시켜야 하기 때문이다.
웹 컨테이너는 클라이언트에 response의 일부로 세션 ID를 보내면 클라이언트는 다음 요청부터 Request의 일부로 세션ID를 사용한다.
웹 컨테이너가 클라이언트에 세션ID를 전송하면 클라이언트는 이 정보를 쿠키에 저장한다.
쿠키는 세션 ID와 관련이 없기 때문에 웹 브라우저에서 쿠키를 허용하지 않도록 설정하여 해킹을 방지하는 것이 중요하다.
클라이언트의 쿠키가 활성화 되지 않아 있다면, 모든 get방식에 jssesionid를 두어 이를 이용하여 세션을 유지합니다.
7. 표준 액션
|
<jsp:useBean> |
자바빈즈 컴포넌트를 이용 |
|
<jsp:getProperty> |
자바빈즈 컴포넌트에서 속성값을 가져온다. |
|
<jsp:setProperty> |
자바빈즈 컴포넌트에 속성값을 설정한다. |
|
<jsp:include> |
요청처리 단계 동안 jsp 페이지나 서블릿의 응답을 포함한다.(수행 결과 포함) |
|
<jsp:forword> |
요청의 처리를 다른 페이지로 넘긴다.(제어권도 넘어감) |
|
<jsp:param> |
다른 페이지로 매개변수 값을 넘겨준다. |
|
<jsp:plugin> |
자바 플러그인을 사용할 수 있도록 해준다.(결과 포함) |
|
<jsp:root> |
커스텀 태크에 대한 표준 엘리먼트와 네임스페이스 속성 정의 |
|
<jsp:text> |
XML 구현 방식을 적용하는 경우 데이터 영역 포함 |
|
<jsp:attribute> |
표준 액션 태그 또는 커스텀 태그의 속성을 엘리먼트 내용 부분에 정의하려는 경우 사용 |
|
<jsp:body> |
엘리먼트의 내용 부분을 명시적으로 정의 |
|
<jsp:element> |
XML 엘리먼트를 동적으로 생성 커스텀 태크 활용 시 태그 파일에서 사용하는 액션태그 |
|
<jsp:doBody> |
태그 파일에 정의된 커스텀 태그를 사용하고 있는 JSP 파일에서 태그의 바디 부분을 추출하여 처리하는 경우 |
|
<jsp:invoke> |
태그 파일에 정의된 커스텀 태그를 사용하고 있는 JSP 파일에서 태그에 정의된 속성의 값을 추출하여 처리하려는 경우 |
|
<jsp:output> |
JSP의 수행 결과로 XML 형식을 생성할 때 XML 선언문이나 DTD 선언문을 추가하고자 하는 경우 |
ex) <%@ include file="URL" %>
<jsp:include page="URL" flush="false" />
Jsp 액션 태그의 flush 속성을 true 로 하면 먼저 버퍼의 내용을 클라이언트에 전송하게 되는데 이때 헤더정보도 같이 전송하기 때문에 추후 헤더정보의 추가가 되지 않는다.
비교)include 액션 vs include 지시어
include 액션 : include 되는 페이지의 결과를 원래 페이지에 포함
include 지시어 : include 되는 페이지의 소스를 원래 페이지와 합쳐서 컴파일
8. 필터
웹 컨테이너가 필터를 인스턴스화할 때 init() 메소드를 호출한다. 필터가 호출되기 전에 설정할 작업을 수행한다.
대표적인 작업은 FilterConfig객체를 지역변수에 저장하는 것이다.
필터에서 실제로 작업이 이루어지는 메소드는 doFilter()이다. 이 메소드는 ServletRequest, ServletResponse, FilterChain 객체를 인자로 받는다.
FilterChain 인터페이스의 doFilter()를 이용하여 필터를 차례로 수행하는 과정은 개념적으로 Stack에 대한 메소드 호출처럼 작동한다.
웹 컨테이너가 필터 인스턴스를 제거할 때 destroy() 메소드를 호출한다. 인스턴스가 삭제되기 전에 수행해야 할 작업들이 코딩된다.
필터는 DD(Deploy Descriptor: web.xml)에 정의하며, 컨테이너에 의해 요청이 들어올 때,
최초 요청시 init을 통하여 초기화 되어, doFilter를 통해 선행 처리되어 다른 필터 또는 서블릿이 수행됩니다.
참고: void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
필터는 DD에 정의된 순서에 의해서 아래의 그림처럼 동작합니다.
출처 : http://onjava.com/onjava/2003/11/19/graphics/tfessh-pic-1.gif
FilterChain는, 요청의 호출 체인을 개발자가 다루도록 하기 위하여, 서블릿 컨테이너에 의해 제공되는 클래스로서
Filter는 FilterChain를 사용해, 체인내의 다음의 필터를 호출하거나 호출중의 필터가 체인내의 마지막 필터인 경우는, 체인의 끝에 있는 서블릿등을 호출합니다.
필터는 일반 자바 컴포넌트로 서블릿으로 요청이 넘어가기 전에 요청을 가로채어 특정한 작업을 수행할 수 있다.
필터 그 자체로 완전한 컴포넌트이지만 체인식으로 연결하여 사용할 수 있다.
컨테이너는 DD에 정의된 <filter> 태그와 <filter-mapping> 태그를 이용하여 언제 필터를 실행할지 알고 있다.
Examples that have been identified for this design are
1) Authentication Filters
2) Logging and Auditing Filters
3) Image conversion Filters
4) Data compression Filters
5) Encryption Filters
6) Tokenizing Filters
7) Filters that trigger resource access events
8) XSL/T filters
9) Mime-type chain Filter
9. 태그 라이브러리
JSTL은 표준 커스텀 태그
JSTL은 JSP 페이지의 로직을 담당하는 부분인 if, for, while, DB 처리 등을 표준 커스텀 태그로 제공함으로써 코드를 깔끔하게 하고 JSP 페이지의 가독성을 좋게한다.
JSTL과 커스텀 태그도 XML 기반에서 작성되었기 때문에 모든 태그는 시작/종료 태그의 쌍으로 이루어져야 한다.
JSTL core
core는 변수 선언, 삭제 등 변수와 관련된 작업과 if,for 등과 같은 제어문, URL 처리등에 사용된다.
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
|
catch |
body 위치에서 실행되는 코드의 예외를 잡아내는 역할을 담당한다. <c:catch> |
|
choose |
자바의 switch 문과 같지만, 조건에 문자열 비교도 가능하다. 한 개 이상의 <when> 과 한 개의 <otherwise> 서브 태그를 갖는다. <c:choose> |
|
if |
조건문을 사용할 때. <c:if> |
|
import |
웹 어플리케이션 내부의 자원과 http, ftp 와 같은 외부에 있는 자원을 가져온다. 자원을 자유롭게 가공할 수도 있고, 편집도 가능하다. <c:import> |
|
forEach |
객체 전체에 걸쳐 반복 실행을 할 때 사용. <c:forEach> |
|
forTokens |
자바의 StringTokenizer 클래스를 사용하는 것과 같다. <c:forTokens> |
|
out |
JSP의 표현식을 대체하는 것으로 가장 많이 사용된다. <c:out> |
|
otherwise |
<choose>의 서브 태그로 <when> 태그 다음에 표시되는 것으로 조건을 만족하지 못한 경우에 사용한다. <c:otherwise> |
|
param |
<import> 태그의 URL 뒤에 파라미터로 붙여서 사용할 수 있다. <c:param> |
|
redirect |
response.sendRedirect() 를 대체하는 태그로 지정한 다른 페이지로 이동한다. <c:redirect> |
|
remove |
JSP의 removeAttribute() 와 같은 역할을 한다. (page|request|session|application) 범위의 변수(속성)을 제거한다. <c:remove> |
|
set |
JSP의 setAttribute() 와 같은 역할을 한다. (page|request|session|application) 범위의 변수(속성)을 설정한다. <c:set> |
|
url |
쿼리 파라미터로부터 URL을 생성한다. <c:url> |
|
when |
<choose> 의 서브 태그로 조건을 만족한 경우에 사용한다. <c:when> |
JSTL XML
XML 출력, 흐름 제어, XML 변환 등의 작업에 사용된다.
<%@ taglib prefix="x" uri="http://java.sun.com/jsp/jstl/xml" %>
|
choose |
<c:choose/> 태그와 같은 기능. <x:choose> |
|
out |
XPath에 지정한 패턴에 따라 XML 내용을 출력. <x:out/> |
|
if |
조건문의 사용. <x:if/> |
|
forEach |
XPath에 따라서 해당하는 엘리먼트 수 만큼 반복해서 수행. <x:forEach> |
|
otherwise |
<c:otherwise/> 와 같다. <x:otherwise> |
|
param |
파라미터 사용시에 사용. <x:param> |
|
parse |
XML 문서를 읽어서 파싱한다. <x:parse/> |
|
set |
XPath에 따라 선택된 내용을 변수에 저장. <x:set/> |
|
transform |
XML과 XSTL 파일을 결합해서 새로운 형식의 문서를 생성한다. <x:transform/> |
|
when |
<c:when/> 과 같다. <x:when> |
JSTL fmt
JSTL 국제화, 지역화 태그로 다국어 문서를 처리할 때 우용하며 날짜와 숫자 형식을 다룰 때 사용된다.
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
|
requestEncoding |
request.setCharacterEncoding() 과 같은 역할을 한다. |
|
setLocale |
다국어를 지원하는 페이지를 만들기 위해 사용할 경우 ResourceBundle 로 불러오는 *.properties 파일들과 연계되어서 사용된다. |
|
timeZone |
타임 존을 적용할 때 사용 |
|
setTimeZone |
특정 scope의 타임 존을 설정할 때 사용 |
|
bundle |
properties 확장자를 사용하는 자원 파일을 읽어오는 역할 |
|
setBundle |
페이지 전처에서 사용할 수 있는 번들을 지정하는데 사용 |
|
message |
번들 태그에서 정한 값들을 가져온다 |
|
param |
<fmt:message> 태그의 서브 태그로 <fmt:message> 태그에서 설정하지 않은 값을 채워준다. |
|
formatNumber |
숫자 형식을 표현할 때 사용 |
|
parseNumber |
문자열로부터 수치를 파싱해 낸다. 즉 문자열을 숫자로 변환 시에 사용 |
|
formatDate |
날짜 형식을 표현할 때 사용 |
|
parseDate |
문자열로부터 날짜를 파싱해 낸다. 즉 문자열을 날짜로 변환 시에 사용 |
JSTL sql
DataSource 를 이용해서 SQL 을 처리하는 작업등에 사용됨
<%@ taglib prefix="sql" uri="http://java.sun.com/jsp/jstl/sql" %>
|
transaction |
트랜잭션을 구현할 때 사용 |
|
query |
sql 태그의 속성 또는 body 에 정의된 SQL 쿼리 문장을 실행. executeQuery()와 같은 기능 |
|
update |
sql 태그의 속성 또는 body 에 정의된 SQL 쿼리 문장을 실행. executeUpdate()와 같은 기능 |
|
param |
java.sql.PreparedStatement.setString()의 역할 |
|
dateParam |
java.sql.PreparedStatement.setTimestamp()의 역할 |
|
setDataSource |
DataSource 를 지정 |
JSTL functions
JSTL 에서 제공하는 각종 함수를 사용해서 문자열이나 콜렉션들을 처리한다.
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
|
contains(String string, String substring) |
string 이 substring 을 포함하면 true 반환 |
|
containsIgnoreCase(String string, String substring) |
대소문자 관계없이, string 이 substring 을 포함하면 true 반환 |
|
endsWith(String string, String substring) |
java.lang.String.endsWith() 와 같음 |
|
escapeXML(String string) |
string 에 XML과 HTML 에서 <,>,&,'," 문자들을 각각 <, > & ', " 로 바꿔준 뒤 문자열을 반환 |
|
indexOf(String string, String substring) |
java.lang.String.indexOf() 와 같음 |
|
join(String[], String separator) |
배열 요소들을 separator 를 구분자로 하여 모두 연결해서 반환 |
|
length(Object) |
java.lang.String.length() 와 같음 |
|
replace(String string, String before, String after) |
java.lang.String.replace() 와 같음 |
|
split(String string, String separator) |
java.lang.String.split() 와 같음 |
|
startsWith(String string, String substring) |
java.lang.String.startsWith() 와 같음 |
|
substring(String string, int begin, int end) |
java.lang.String.substring() 과 같음 |
|
substringAfter(String string, String substring) |
string 에서 substring이 나타나는 이후의 부분에 있는 문자열 반환 |
|
substringBefore(String string, String substring) |
string 에서 substring이 나타나는 이전의 부분에 있는 문자열 반환 |
|
toLowerCase(String string) |
java.lang.String.toLowerCase() 와 같음 |
|
toUpperCase(String string) |
java.lang.String.toUpperCase() 와 같음 |
|
trim(String string) |
java.lang.String.trim() 과 같음 |
10. 커스텀 태그
한 번 작성한 커스텀 태그는 재사용이 가능하다.
JSP의 스크립트를 사용하지 않으므로 자바 문법에 의존적이지 않다.
자바 클래스 파일 기반의 태그 라이브러리 사용
자바 클래스 파일 <=> TLD 파일 <=> web.xml <=> JSP 페이지
커스텀 태그 정의 클래스 파일 등록 TLD 등록 커스텀 태그 사용
javax.servlet.jsp.tagext의 interface를 구현한다.
(BodyTag, IterationTag, SimpleTag, Tag )
=> TagSupport, BodyTagSupport, SimpleTagSupport 클래스를 상속받아 사용
<%@ taglib prefix="tag" uri="/WEB-INF/tlds/WelcomeTag.tld" %>
태그 파일을 태그 라이브러리로 사용
태그 파일 <=> JSP
(.tag) 페이지
<%@ taglib prefix="tagFile" uri="/WEB-INF/tags" %>
11. 환경 설정
DD 파일 : WEB-INF/web.xml
class 파일 : WEB-INF/classes/
웹 컨테이너에 서블릿을 배포하려면 DD(Deployment Descriptor)를 이용한다.
DD내에서 서블리과 URL을 매핑하기 위해서 서블릿의 패키지명, 클래스명과 내부이름을 매핑하기 위해
<servlet> 태그를 사용하고 하위태그로는 <servlet-name> <servlet-class>를 가진다.
내부이름과 URL을 매핑하기 위하여 <servlet-mapping> 태그를 사용하고 하위태그로 <servlet-name> <url-pattern>을 가진다.
taglib 설정
|
<taglib>
<taglib-uri>
/WEB-INF/tlds/WelcomeTag.tld
</taglib-uri>
<taglib-location>
/WEB-INF/tlds/welcomTag.tld
</taglib-location>
</talib> |
servlet 설정
|
<serlvet>
<serlvet-name>Controller</servlet-name>
<servlet-class>ch18.controller.Controller</serlvet-class>
<init-param>
<param-name>propertyConfig</param-name>
<param-value>xxxx</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Controller</servlet-name>
<utl-pattern>*.do</url-pattern>
</servlet-mapping> |
에러 페이지 설정
|
<error-page>
<error-code>404</error-code>
<location>/error/404code.jsp</location>
</error-page> |
filter 설정
|
<filter>
<filter-name>EncodingFilter</filter-name>
<filter-class>jef.application.channel.filter.EncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>EUC-KR</param-value>
</init-param>
<init-param>
<param-name>responseContentType</param-name>
<param-value>text/xml</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>EncodingFilter</filter-name>
<url-pattern>*.hi</url-pattern>
</filter-mapping> |
welcomeTag.tld 파일을 아래와 같이 기술
|
<description>JSP1.2 example</descript>
<display-name>Exampole</display-name>
<tlib-version>1.0</tlib-version>
<short-name>welcomeTag</short-name>
<tag>
<name>welcome</name>
<tag-class>ch17.WelcomeTag</tag-class>
<body-content>empty</body-content>
</tag> |
12. Model1, Mode2, MVC 패턴
Model 1
웹 브라우저의 요청을 받아들이고, 웹 브라우저에 응답해주는 처리에 대해 JSP 페이지 단독으로 처리하는 구조
Web <-> View <-> Model <-> DB
Browser (JSP Page) (JavaBean)
장점
단순한 페이지 흐름으르 인해 개발 기간이 단축
MVC 구조에 대한 추가적인 교육이 필요없고 개발팀원의 수준이 높지 않아도 된다.
중소형 프로젝트에 적합
단점
웹 어플리케이션이 복잡해질 수록 유지 보수가 힘들다.
디자이너와 개발자 간의 원활한 의사소통이 필요하다.
Model 2
요청 처리, 데이터 접근, 비지니스 로직을 포함하고 있는 컨트롤 컴포넌트와 뷰 텀포넌트가 엄격히 구분되어져 있다.
뷰는 어떠한 처리 로직도 포함하고 있지 않다.
-> Controller <-> Model <-> DB
Web (Servlet) (JavaBean)
Browser <- View
(JSP Page)
장점
비지니스 로직과 뷰의 분리로 인해 어플리케이션이 명료해지며 유지 보수와 확장이 용이하다
개발자와 디자이너의 작업이 분리되어져 역할과 책임 구분이 명확하다
단점
설계를 위한 시간이 많이 소요되므로 개발 기간이 증가한다.
MVC 구조에 대한 개발자들의 이해가 필요하다
MVC(Model-View-Controller)
View
화면에 내용을 표출
단지 정보를 보여주는 역할만 담당
JSP 페이지
Model
DB와의 연동을 통해서 데이터를 가져와 어떤 작업을 처리하거나 처리한 작업의 결과를 데이터로서 DB에 저장하는 일을 처리
어플리케이션의 수행에 필요한 데이터를 모델링하고 비지니스 로직을 처리
JavaBean
Controller
View와 Model 사이의 어플리케이션의 흐름을 제어
사용자의 요청을 받아서 모델이 넘기고, 모델이 처리한 작업의 결과를 뷰에 보내주는 역할
Servlet
-> Controller <-> Model <-> DB
Web (Servlet) (JavaBean)
Browser <- View
(JSP Page)
13. 분산 환경에서 세션관리
다음과 같은 환경에서 노드가 2개일 때, HttpSession이 어떻게 이동되는지 설명해 보시오.
(요청, 로드 밸런싱 서버, VM, 컨테이너, 서블릿, 세션, HttpSession) 단어를 이용하시오.
분산 웹 애플리케이션
다중 노드간 애플케이션 복제
다중 노드의 클러스터링
로드 밸런싱 환경
동일 클라이언트에서 보낸 요청이 동일 서블릿의 서로 다른 인스턴스로 넘어 갈 수 있다.
HttpSession은 웹 애플리케이션당, 하나의 세션ID당 1개만 존재한다. VM의 수와는 무관하다.
┌──────┐ ┌──────┐
│1번 컨테이너│ │2번 컨테이너│
│ VM │ │ VM │
└──────┘ └──────┘
\ /
\ ┌───────┐ /
\ │로드밸런싱서버│ /
│ VM │
└───────┘
|
┌────┐
│브라우저│
└────┘
브라우저의 요청은 로드밸런싱서버에 의해 요청 처리가 적은 컨테이너쪽으로 요청을 보내면,
VM위에 동작중인 컨테이너는 세션 유지를 위하여,
HTTPSession을 생성하며 자체 컨테이너에 보관하고 서블릿 처리후 브라우저에 응답합니다.
HTTPSession 객체는 다시 로드 밸런싱서버에 의해 다른 컨테이너로 주기적으로 복제되어,
분산 웹 환경내에서 클러스터링 됩니다.
단, 로드밸런싱서버의 역활은 로드 밸런싱 및 세션복제를 담당합니다.
14. 스트럿츠 이해
스트럿츠의 주요 컴포넌트인 액션 서블릿(ActionServlet), 폼 빈(ActionForm),
액션 객체(Action), struts-config.xml 용어를 사용하여 스트럿츠가 어떻게 작동하는지 설명해 보시오.
브라우저 요청시 Controller에 해당하는 ActionServlet이 최초 요청을 받아,
struts-config.xml에 정의된 설정에 따라 Model에 해당하는 ActionForm을 생성하여
Logic을 담당하는 Action에 넘겨 로직을 처리후, JSP 또는 Velocity등의 View로 응답합니다.
참고: http://www.ibm.com/developerworks/kr/library/j-struts/index.html
http://www.oracle.com/technology/products/jdev/howtos/jsp/struts_app.jpg
