잊지 않겠습니다.

'servlet'에 해당되는 글 3건

  1. 2013.09.13 HTTP protocol과 REST
  2. 2013.09.12 20. Controller - Spring 2.x
  3. 2013.09.12 18. Java Web Application - web.xml (2)

* 사내 강의용으로 사용한 자료를 Blog에 공유합니다. Spring을 이용한 Web 개발에 대한 전반적인 내용에 대해서 다루고 있습니다.



WebApplication은 HTTP Protocol로 동작하는 네트워크 프로그래밍의 일종입니다. 

이 정의가 조금은 의문스러워보이실지 모르겠지만, 저희는 지금 네트워크 프로그래밍을 하고 있는것입니다. 다만 이 네트워크를 처리해주는 것이 Servlet Container가 됩니다. 네트워크 프로그래밍은 매우 어려운 작업이지만, 지금 우리가 할 수 있는 가장 큰 이유는 Servlet Container가 이 일을 처리해주고 있기 때문입니다. 이는 매우 큰 의미를 갖습니다. 더이상 개발자들은 이 어려운 네트워크 문제를 다루지 않고, 처리하고자 하는 BL에만 집중할 수 있다는 점이, 오늘날의 성공적인 web application 환경을 만들어주게 되었습니다.  네트워크 처리 부분만을 의미하는 것으로 web application server 라는 표현을 사용하기도 합니다. 

위에서 보시는것처럼 web application server는 web으로 동작하는 application만을 의미하게 됩니다. 또한 Java EE(java enterprise edition)의 명세 및 구현된 web application 기술에 대한 구현체가 servlet container라고 할 수 있습니다. 이에 따라 servlet container는 다음과 같은 정의를 내릴 수 있습니다. 

servlet container = web application server + Java EE web application 기술 구현체

가장 널리, 그리고 무료로 사용될 수 있는 servlet container는 다음과 같습니다. 

tomcat : 가장 오랫동안 servlet 기술 명세에 대한 reference 구현체였으며, 가장 잘 알려진 servlet container입니다. 
jetty : 실험적 시도를 가장 과감하게 도입하는 것으로 유명합니다. 또한 속도가 가장 빠르고 가벼운 servlet container로 유명합니다.
grizzly : 현 servlet 기술 명세에 대한 reference인 glassfish의 servlet framework입니다. 제한적 무료라서 그런지, tomcat에 비해서 대중성이 조금 떨어지고 있다는 느낌이 들긴 합니다. 


HTTP Protocol

HTTP는 다른 Protocol과는 조금 다른 특징을 가지게 됩니다. 일반적으로 network protocol은 size나 해석의 문제에 의하여 압축되고, 특정 문자로 해석되도록 데이터를 만드는 것이 일반적입니다. 주소번지 1번지부터 12번지까지는 특정 어떤값을 이용하는 식으로요. 그렇지만 HTTP Protocol은 String을 그대로 사용하고 있습니다.  만약에 daum 사이트에 갔을 때, http는 어떤 통신을 하는지 한번 간단하게 알아보도록 하겠습니다. 

먼저 request는 다음과 같이 발생됩니다.

GET / HTTP/1.1
Host: www.naver.com:8000
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
DNT: 1
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: UTF-8,*;q=0.5
Cookie: JSESSIONID=1q5bdgf2p3b22nz1n133l3qd

모든 HTTP Protocol은 기본적으로 CR + LF에 의하여 한개의 항목이 끝나는 것을 지정합니다. 그리고 데이터는 {Name}: {Value} 형태로 구성이 됩니다. 이 형태는 매우 중요합니다. 공백과 :의 위치까지 정확하게 잡혀있는 Protocol format이 됩니다. 만약에 우리가 HTTP Protocol을 직접 만들어서 보내주고 싶다면 이와 같은 형태로 데이터를 구성해서 보내주면 됩니다. 

지금까지 보신 위 코드가 HTTP Header 가 됩니다.  개발시에 자주 이야기가 나오던 HTTP Header에 특정 데이터를 넣어서 보낸다던지, 특정 데이터를 얻어오는 일들이 모두 위의 Text로 구성이 됩니다. 

다음은 response입니다. 

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 May 2013 01:24:54 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
P3P: CP="CAO DSP CURa ADMa TAIa PSAa OUR LAW STP PHY ONL UNI PUR FIN COM NAV INT DEM STA PRE"
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip

404


보시면 request와 비슷한 내용이 return되는 것을 알수 있는데, 아래 부분에 약간 다른 내용이 있습니다. 이 부분이 Body입니다. Body는 Header다음에 CR + LF + CR + LF 후에 나오는 text 영역이 됩니다. 우리가 만드는 HTML 부분이 되는 것이 일반적입니다. 

HTTP Protocol의 request type

request의 첫줄에 나오는 GET / HTTP/1.1에 주목할 필요가 있습니다. 이 부분은 지금까지 사용되는 부분과 조금 다릅니다. 이 부분을 http method라고 불리우는 영역입니다. HTTP method에 따라서 url의 parameter를 server에서 달리 해석하게 됩니다. 

1. GET
우리가 가장 자주 보는 형태입니다. parameter는 ?로 시작되고, =로 key와 value가 설정이 됩니다. 그리고 다른 key가 있는 경우에는 &로 연결이 됩니다. 따라서 형태는 다음과 같이 구성이 될 수 있습니다. 


가장 주로 사용되는 형태입니다. HTTP Protocol의 정의상으로는 GET는 정보의 조회시에 사용하는 형태입니다. <a> tag나 browser의 url로 접근하는 경우에는 모두 GET으로 동작하게 됩니다. 

2. POST
역시 자주보이는 형태입니다. parameter의 구성방법역시 GET과 동일합니다. 다만 parameter를 보내는 방법에 큰 차이를 가지고 있습니다. GET에서 parameter를 이용해서 구성을 했지만, POST는 body에 GET에서 보내줬던 paramter를 넣어서 보내주게 됩니다. 이 방법은 사용자에게 parameter를 노출시키지 않는 장점을 가지고 있고, GET에서 불가능한 대용량 대이터를 보내는 것이 가능합니다. 그리고 file upload 시에도 POST 방식을 사용하게 됩니다. HTTP protocol에서는 기본적으로 update의 의미를 가지고 있습니다. 

위 GET/POST는 가장 많이 사용되고 있는 HTTP method입니다. 그리고 Browser에서 기본적으로 지원을 하고 있습니다. 그렇지만, 아래 나오는 method들은 구형 browser에서는 지원되지 않고 있습니다. 그리고 GET/POST 이외에는 parameter를 보내지 못합니다. 이 부분은 RFC 문서에 정의된 내용으로 HTTP 1.1 이상의 버젼에서는 추후 지원할 수도 있습니다.  

3. DELETE
조금은 생소한 method입니다. HTTP protocol에서는 이름 그대로 delete의 의미를 가지고 있습니다. 

4. PUT
Create/Insert의 의미를 갖는 method 입니다. 

5. TRACE
보낸 request를 그대로 다시 보내주길 원하는 method입니다. echo server나 server의 상태가 원활한지를 알아보는 방법으로 사용됩니다.  이 method는 매우 심각한 문제를 가지고 있습니다. XST(Cross-Site Tracing)이라는 악의적 공격방법을 이용해서 사용자의 request에 들어있는 인증정보를 빼돌릴때 사용이 됩니다. 그래서 TRACE를 지원하는 web server들은 모두 심각한 오류를 가지는 것으로 보고되며, 모든 web server는 TRACE method를 무효할 것을 권장하고 있습니다. 

6. OPTIONS
Web Server에서 HTTP Method중 어떤 것들을 지원하는지 알아보는데 사용됩니다. 

7. CONNECT
Proxy에서 사용됩니다. Http TLS(Transport Layer Security) Tunnelling을 요청할 때 사용됩니다. CONNECT로 보내지는 method는 그 서버를 통해서 다른 서버에 접속하게 되는 것을 요청하게 됩니다. 

8. HEAD
GET과 동일한 정보를 return합니다. 다만 차이를 갖는 것이 GET은 Body에 데이터를 넣어서 보내지지만, HEAD는 Header에 Message-Body에 body를 모두 넣어서 보내게 됩니다. HEAD method는 browser에서 cache를 사용할 때 주로 이용합니다. 


위 method를 이용한 결과는 HTTP result라는 숫자로 표시가 되는데요. 이는 response의 첫줄에 나오는 숫자가 Return에 대한 결과입니다. 우리가 자주 보는 HTTP result의 결과가 바로 이것입니다. 

1. 2xx - Success
# 200 : OK
# 201 : Created - POST나 PUT에 의해서 새로운 Resource가 생성되었음을 나타내는 result code입니다.
# 202 : Accepted - async http request가 들어왔을 때, 그 request가 수용되었음을 나타냅니다. 
# 203 : Partial Information - return되는 정보는 cached된 것이거나, 내부 정보임을 의미합니다. 
# 204 : No Response - Response가 정상적으로 처리되었지만, Output의 내용이 없음을 의미합니다. 주로 Body가 비어있는 경우에 204를 return 합니다.

2. 3xx - Redirect
# 301 : Moved - 요청된 URL의 페이지가 다른 곳으로 이동되었음을 나타냅니다.
# 302 : Found - 요청된 URL의 페이지에서 다른 곳으로 이동하는 것을 원하는 것을 나타냅니다. 301과 비슷하지만, 302의 경우에는 Form을 POST로 넘겼을 때, 그 결과에 대한 Accept의 의미로 사용됩니다.
# 303 : Method - Found와 같은 의미로 사용되지만, Found는 URL로 이동됨을 나타냅니다. Method는 Body에 있는 Document를 이용해서 표시하는 것을 의미하게 됩니다.
# 304 : Not modified - 변경된 상황이 없기 때문에 Cache에 있는 내용을 이용해서 표시하라는 것을 의미합니다.

3. 4xx - Client Error
# 400 : Bad Request - HTTP Protocol에 어긋난 request가 입력되었습니다.
# 401 : Unauthorized - 인증되지 않은 HTTP Request가 들어왔습니다.
# 402 : Payment Required - Http Head에 있는 정보를 변경해서 다시 보내주는 것을 요청할때 사용됩니다.
# 403 : Forbidden - 인증되었지만, 권한이 없음을 나타냅니다.
# 404 : Not Found - Resource가 없는 URL에 요청되었음을 나타냅니다. 우리가 Spring으로 web을 개발할때, 처음에 자주 볼 수 있는 에러입니다. Controller 뿐 아니라 View File이 없는 경우에도 404 Not Found가 표시됨을 유의해주시길 바랍니다. 

4. 5xx - Server Error
# 500 : Internal Error - 서버 내부의 에러입니다. java나 .net에서 exception이 발생했을 때, 이것을 처리하지 않을때 나오는 에러입니다.
# 501 : Not Implemented - 아직 구현되지 않은 URL을 호출했습니다. 이는 404와는 다른 에러입니다. 404의 경우에는 아애 없는 URL이 호출된 상황이고, 501의 경우에는 구현되지 않았지만, URL resource는 존재할 때 사용됩니다.
# 502 : Timeout - RFC에 의해서 정의된 에러는 아닙니다. 그렇지만 몇몇 WebServer들은 구현되어있는 에러코드로, Server의 BL로직이 너무 오래 걸릴때, 에러로 return 해줍니다. 


웹의 구조적 아키텍쳐

apache httpd를 시작한 Roy Fielding은 web은 주요 제약점에 의해서 확장성이 좌우되는것을 알게 되고, 그에 대한 구조적 스타일을 다음과 같이 정의했습니다. 

1. Client / Server
웹은 client/server 기반 system으로 client/server 규약의 핵심은 관심의 분리입니다. 웹의 일괄된 인터페이스를 따른다는 가정하에, Client와 Server는 각자의 언어 및 기술을 이용해서 독립적으로 구현되고 배포가 가능하게 됩니다. 

2. Uniform interface
웹을 구성하는 Client/Server/Network 간의 interface는 일관성에 기반하고 있습니다. 이러한 구조가 붕괴가 되는 경우, 현 웹 커뮤니케이션체계는 붕괴가 되어버립니다. 
이 인터페이스는 다음과 같은 정의들을 보일 수 있습니다. 

# 리소스 식별 : URI로 구분될 수 있는 resource는 unique하기 때문에, 고유 식별자로 사용될 수 있습니다.
# 표현을 통한 Resource 처리 : HTML, JSON과 같은 web resource는 표현 방법이 정해져있지 않습니다. HTML을 그냥 text로 보여줘도 되고, web browser에서 보이듯이 rendering해서 표시를 해도 괜찮다는 뜻입니다. 이는 Document-View 구조와 같이 Resource에 대한 처리는 Client에게 맡긴다는 정의로도 볼 수 있습니다.
# 자기 서술적 메세지 : HTTP protocol의 header는 자신에 대한 서술적 메세지를 포함합니다. 그리고, 요청에 대한 처리는 전적으로 요청에 대한 응답자에서 결정하게 됩니다. 
# Application 상태 엔진으로서의 Hyper-media : resource의 상태표현은 resource의 link를 포함합니다. 따라서 모든 resource는 실타래처럼 연결되기 때문에 사용자들은 정보와 application을 직접적인 방식으로 훝어보는 것이 가능하게 됩니다. 이는 HTML의 표준적인 특징중 하나입니다.

3. Layered System
우리가 구성하는 MVC와 같은 Layered System이 아닌 Browser-proxy-gateway-switch-web server 와같은 Layer가 구성되는 network 기반의 중간계층을 사용할 수 있는 구조적 특징을 갖습니다. network 기반의 중간계층의 경우에는 보안의 강화 또는 응답 캐싱, 부하를 분산하는 용도로 주로 사용됩니다. 

4. Cache
cache는 웹구조의 중요한 제약조건중 하나입니다. 캐시는 웹자체의 전체적인 비용을 줄일 수 있는 기술적 요건이며 server, network, client 모두에 위치가 가능하게 됩니다. 

5. Stateless
웹의 가장 큰 특징중 하나입니다. web server가 client의 상태를 직접 관리할 필요가 전혀 없다는 것입니다. 따라서 client는 server와 상호작용하는 관련 상황정보를 직접 관리를 해야지 됩니다. 이는 web server가 client와의 복잡한 연결을 위해 필요한 상태 관리를 전혀 하지 않는다는 점입니다. 이를 다른 말로 FF(fire and forget)이라고도 합니다. 이는 장점도 단점도 아닙니다. 비용상의 trade-off라고도 할 수 있습니다. 

6. Code-on-demand
웹은 주문형 코드를 많이 사용합니다. 이 제약조건은 script나 plugin과 같은 실행가능한 program을 일시적으로 program에 전송하여 client가 실행할 수 있도록 합니다. 그렇지만 이는 client와 server간의 강한 결합을 가지고 오게 되는데. 이는 web에 대한 확장성을 막아버릴 수 있기때문에 최대한 지양해야지 되는 구조라고 할 수 있습니다.

이러한 구조적 스타일에 기반한 웹의 확장은 2000년 Roy Fielding에 의해서 'Representational State Transfer'라고 이름을 붙여 발표하게 되었습니다. 그리고 이 논문의 제목은 지금 REST라는 용어로 더욱더 많이 사용되고 있습니다. 

REST는 어느날 갑자기 나온것이 아니라, 웹의 구조적인 특징을 이용하고, 그에 대한 안정화로서 나온 기술입니다. 어찌보면 기술이라기보다는 'Style'이라고 할 수 있는 방법입니다. REST에 충실한 구조를 RESTful 하다는 용어로 사용하고 있고, 이는 다음과 같은 특징을 가지고 있습니다. 

1. URI 식별자 설계
# '/'는 계층 관계를 나타내는데 사용됩니다.
# URI의 마지막 문자로 '/'는 사용하지 않습니다.
# '-'는 URI의 가독성을 높이는데 사용합니다.
# '_'은 URI에서 사용하지 않습니다.
# URI는 소문자로 구성을 합니다.
# 파일 확장자는 URI에 포함하지 않습니다. 파일 확장자는 URI를 통해 얻어질 수 있는 media-type에 따라 결정이 됩니다.

2. URI 디자인
# Document/Object의 이름은 단수를 이용한다 (ex: http://www.daum.net/leagures/teams/players/report)
# Collection이 표시되는 경우, 복수를 이용한다 (ex: http://www.daum.net/leagures/teams/players)
# 제어가 발생되는 URI는 동사나 동사구를 이용한다 (ex : http://www.daum.net/students/morgan/register)
# CRUD 기능을 나타내는 것은 URI에 사용하지 않는다. 
- 이는 REST API를 구성할 때 사용되는 규칙입니다. 
- 위에서 살펴본 GET/POST/DELETE/PUT을 이용한 URI를 구성해서 CRUD 기능을 만들어주는 것이 권장됩니다.

3. input parameter
# parameter의 경우에는 URI query라는 이름으로 사용됩니다. 
# URI query의 경우에는 검색기준으로 사용되는 것이 일반적입니다. 이는 HTTP GET method의 사용방법과 연관있습니다.

4. http method
# GET method는 리소스의 상태표현을 얻는데 사용됩니다.
# HEAD method는 응답에 대한 header만을 얻어올 때 사용합니다.
# PUT method는 리소스를 생성하거나 갱신하는데 사용합니다.
# POST method는 리소스를 생성하거나 갱신하는데 사용합니다. POST와 PUT는 일반적으로 같은 목적으로 사용됩니다. 다만 사람들끼리의 암시적인 약속으로 Create시에는 PUT을, Update에서는 POST를 사용하는 것이 일반적입니다.
# Control이 발생되는 URI는 반드시 POST에 의해서 실행됩니다.
# DELETE는 Resource를 삭제할 때 사용됩니다.
# OPTIONS는 resource의 사용 가능한 action method가 무엇인지를 알기위해서 구성됩니다.


Summary 

이번에는 HTTP에 대한 기본적인 이론에 대해서 알아봤습니다. HTTP는 우리가 만드는 모든 web application의 핵심기술입니다. 다만 기술의 구현은 servlet container 또는 web server에서 담당하지만, 그에 대한 동작을 알아보는 것은 개발시 디버그등에 매우 유리하게 만들 수 있습니다. 그리고 URI의 디자인은 URI 자체의 문서화 뿐 아니라 Google에서의 검색의 가장 큰 기준이 됩니다. 여기서 나온 내용들은 꼭 알아두시길 바랍니다.


저작자 표시 비영리 변경 금지
신고
Posted by xyzlast Y2K
TAG http, Rest, servlet

* 사내 강의용으로 사용한 자료를 Blog에 공유합니다. Spring을 이용한 Web 개발에 대한 전반적인 내용에 대해서 다루고 있습니다.


maven을 이용한 기본 web application을 구성하는 방법에 대해서 알아봤습니다. 
servlet을 이용한 web page 개발은 Model 1 또는 Model 2라고 하는 Model에 의해서 구성되게 됩니다. 먼저 Model 1에 대해서 알아보도록 하겠습니다. 

Model 1은 JSP Page에서 JavaBean을 이용해서 직접 DB에 또는 DataSource에 접근하는 방식입니다. Client에서 WebServer로 호출이 되게 되면 SErver에서 요청한 File을 분석하게 됩니다. 이는 JSP 또는 Html 형태로 구성이 되게 되며, JSP의 경우 Servlet Container에서 JavaBean을 이용해서 DB에 접속하고 처리 결과를 조합하여 JSP 호출부에 전송하여 Html 형태로 Client에 response를 보내게 되는 방식입니다.


이러한 방식을 Model 1 이라고 합니다.


이러한 방법의 장/단은 다음과 같습니다.

장점
1. 개발 속도가 빠르다.
2. 개발자의 스킬이 낮아도 배우기 쉬워 빠르게 적용할 수 있다.

단점
1. JSP페이지에서 프리젠테이션 로직과 비즈니스 로직을 모두 포함하기 때문에 JSP페이지가 너무 복잡해 진다.
2. 프리젠테이션 로직과 비즈니스 로직이 혼재되어 있기 때문에 개발자와 디자이너의 분리된 작업이 어려워진다.
3. JSP페이지의 코드가 복작해 짐으로 인해 유지보수 하기 어려워진다.
4. 정교한 Presentation 레이어를 구현하기 힘들다.(유효성 체크, 에러 처리등)

점점 고도화 되어가는 Web Application의 구성에 있어서 Model 1의 코드의 복잡도에 의하여 유지보수를 하는 것이 불가능해졌습니다. 그래서, 기존의 Model 1을 버리고 Model 2 방식으로 변경이 되기 시작했습니다.
참고로, asp .net webform도 Model 1 방식이라고 할 수 있습니다. 


다음은 Model 2입니다.



Servlet에서 Request를 받아 Controller에서 비지니스 로직을 처리하고, View에서 표현할 데이터를 객체로 전달하고, View에서는 그 데이터를 어떻게 표현을 할지를 결정하는 방식입니다. 이때 View는 Presentation Layer라고 지칭이 됩니다. 이러한 방식을 Model 2 라고 합니다. Model 2의 장/단점은 다음과 같습니다.

장점
1. Presenation에서 명확한 역할 분담이 된다.
2. UI 레이어를 단순화 시킴으로서 디자이너도 작업하는 것이 가능하게 된다. - 단지 Display용으로만 사용된다.
3. Presentation 레이어의 정교한 개발이 가능하다. 유효성 체크, 에러 처리와 같은 기능들은 Spring 프레임워크에서 제공한다.
4. Dependency Pull 없이 Dependency Injection만을 이용해서 애플리케이션을 개발하는 것이 가능하다.
5. UI 레이어가 단순해 짐으로서 유지보수가 쉽다.

단점
1. 새로운 기술을 익혀야하는 부담감이 있다.
2. 프로젝트 초반에 개발속도의 저하를 가져올 수 있다.

Spring MVC를 사용하지 않을 때, 거의 모든 Web에서 사용되던 Struct 1과 Struct 2가 Model 2를 가장 잘 지원하는 Web Framework로서 인기를 끌었습니다. 


Web 개발에 들어가기 전에......

지금부터 모든 글(chapter 마지막까지) 은 Servlet 3.0 기반으로 적혀있습니다. servlet 3.0을 사용하기 위해서는 다음 jar가 반드시 pom.xml에 존재해야지 됩니다. scope를 반드시 provide로 해서 넣어주세요.

    <dependency>
      <groupId>org.apache.tomcat</groupId>
      <artifactId>tomcat-servlet-api</artifactId>
      <version>7.0.37</version>
      <scope>provide</scope>
    </dependency>


Spring 2.x 에서의 Model 2 Web 개발

spring web은 Model2에서 사용할 Controller interface를 제공합니다. Controller interface는 다음과 같이 선언됩니다.

public interface Controller {
    ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception;
}


매우 단순한 View 형태입니다. Controller interface를 이용해서 Hello World Web Application을 작성해보도록 하겠습니다.
바로 전에 이야기드린 것 처럼 maven project를 하나 만들어 줍니다.
그리고, 이제 spring mvc에 대한 maven 설정들을 모두 추가합니다.
정의된 maven bean들은 다음과 같습니다.

  <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>3.2.1.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-context-support</artifactId>
      <version>3.2.1.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-webmvc</artifactId>
      <version>3.2.1.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-context</artifactId>
      <version>3.2.1.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-test</artifactId>
      <version>3.2.1.RELEASE</version>
    </dependency>

구성된 Folder중 src/main/webapp/WEB-INF/web.xml 파일을 다음과 같이 수정합니다. 

<?xml version="1.0" encoding="UTF-8"?><web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" 
         xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
  <display-name>mvc.spring01</display-name>
  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
  </welcome-file-list>
  <listener>
    <display-name>ContextLoader</display-name>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  <servlet>
    <servlet-name>spring</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>spring</servlet-name>
    <url-pattern>/app/*</url-pattern>
  </servlet-mapping>
</web-app>


web.xml에 대해서 알아보도록 하겠습니다. 

먼저, listener입니다. web application이 실행될 때, 기본 bean들을 load 하기 위한 listener를 등록합니다. 기본적으로 main/webapp/WEB-INF/applicationContext.xml 파일을 읽어 bean들을 load 시켜줍니다. 

다음은 servlet 설정입니다. front controller로 spring 이라는 이름으로 DispatcherServlet을 로드하고 있는 것을 볼 수 있습니다. 

마지막으로 servlet-mapping입니다. Servlet이 사용될 url path를 설정합니다. 위 xml에서는 /app/* path에서 DispatcherServlet이 실행됨을 지정하고 있습니다. 그리고, DispatcherServlet가 로드될때, 자동으로 spring-servlet.xml bean 정의를 로드합니다. 이는 DispatcherServlet 내부에서 사용할 child appliation context입니다. 파일 이름은 servlet 이름 + "-servlet.xml" 로 자동 결정됩니다. 

따라서, 위 설정의 경우 src/main/webapp 폴더는 다음과 같이 구성되게 됩니다. 


지금보시면 applicationContext가 2개가 등록되게 됩니다. 전에 applicationContext에 대해서 이야기드릴때, root context와 child context가 존재한다는 이야기를 드린적이 있습니다. 이 부분에 대한 내용이 바로 이것입니다. root context가 applicationContext.xml이 되고, child context가 spring-servlet.xml이 되게 되는 것입니다. 이런 root-child context 구조는 기존에는 spring application context를 사용하지만, web 기술은 spring @MVC를 하지 않고 structure 와 같은 다른 web framework를 사용하는 경우를 지원하기 위해서 만들어진 구조입니다.  xml을 사용하게 되면 application context class는 기본으로 지정된 XmlConfigWebApplicationContext를 사용하게 됩니다. 

그런데 왜 이렇게 2개의 application context를 가지도록 설계가 되어 있을까요? 그 이유는 Spring은 먼저 ApplicationContext를 제공하는 Spring-core와 Spring-Bean으로 시작했기 때문입니다. spring-mvc의 경우에는 후에 추가가 된 것이고, 초기에는 spring-core, spring-bean을 이용한 DI와 AOP만을 이용하고, web기술은 struct 와 같은 다른 web framework를 이용했기 때문입니다. 그래서 두개의 설정이 나뉘게 되었고, 그게 지금까지 고정되어 사용되고 있는 것입니다.

@Configuration을 이용한 개발의 경우, Spring 3.x대의 개발에서 좀더 알아보도록 하겠습니다. 기본적으로 Spring 2.x에서 3.0까지는 @Configuration을 이용한 설정을 지원하지 않습니다. 

이제 Controller와 Controller에서 사용될 객체인 HelloString을 만들어보도록 하겠습니다. 

public class HelloSpring {
    public String sayHello(String name) {
        return "Hello " + name;
    }
}

public class HelloController implements Controller {
    @Autowired
    private HelloSpring helloSpring;

    @Override
    public ModelAndView handleRequest(HttpServletRequest request,
            HttpServletResponse response) throws Exception {
        String name = request.getParameter("name");
        String message = helloSpring.sayHello(name);
        Map<String, Object> model = new HashMap<String, Object>();
        model.put("message", message);
        return new ModelAndView("/WEB-INF/view/hello.jsp", model);
    }
}

그리고, HelloSpring는 applicationContext.xml에 HelloController는 spring-servlet.xml에 등록을 합니다.

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="helloSpring" class="com.xyzlast.mvc.spring01.entities.HelloSpring"/>
</beans>

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.2.xsd">
    <bean name="/hello" class="com.xyzlast.mvc.spring01.controllers.HelloController"/>
</beans>


Controller의 등록시, id가 아닌 name으로 /hello로 등록된 것을 주의해주세요. 

이제 이 Controller의 결과를 보여줄 view를 구성하도록 하겠습니다. view 파일의 이름은 webapp/WEB-INF/view/hello.jsp 입니다. 

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Insert title here</title>
</head>
<body>
    <p>${message}</p>
</body>
</html>

그리고 command 창에서 mvn jetty:run 을 실행시키면 이제 웹서버가 구동된겁니다. browser를 통해서 http://localhost:8080/hello/app/hello?name=ykyoon 를 실행시키면 다음 화면을 볼 수 있습니다.

지금까지 만들어지는 과정을 보면 기존 Application을 만드는 과정과는 조금 다른 과정을 보게 됩니다. 먼저, bean을 name으로 등록하게 됩니다. 이건 Controller를 url에 mapping하는 spring만의 방법입니다. 이때는 id가 아닌 name으로 url에 mapping 하게 됩니다. 

그리고 하나 더 주목할 것이 있습니다. ModelAndView객체가 바로 그것입니다. 

ModelAndView는 최종적으로 Controller가 return 해주는 값입니다. ModelAndView에서는 표현될 view의 파일 이름과 view 에서 사용될 Model을 Map형태로 return 시켜주게 됩니다. 이 형태는 jsp를 이용할 때의 형식이고, pdf 또는 파일이 return 될때는 좀 다른 형식을 사용합니다. 이 부분에 대해서는 좀 더 나중에 알아보도록 하겠습니다. 지금은 web page를 보여줄 때는 ModelAndView를 return 한다는 것을 기억해주시면 되겠습니다. 

그리고, 이와같은 web application의 테스트는 어떻게 해야지 될까요? 지금까지 web을 만들고 테스트 하는 것은 web server를 실행시키고, web server의 url을 직접 타이핑을 하던가, 아니면 link를 click-click 해가면서 손으로 테스트를 했습니다. 그런데 이런 테스트 방법은 매우 시간이 많이 걸리고, 개발자들을 불편하게 합니다. 
이제 다시 한번 테스트를 어떤것을 해야지 되는지 확인해보도록 합시다. 먼저, 지금 HelloController는 /hello url로 접근이 가능한지 확인해야지 됩니다. 그리고 Model에 message가 들어있는지 확인되어야지 됩니다. 마지막으로 message가 원하는 값인 Hello + input 임을 확인할 수 있어야지 됩니다. 

정리해보겠습니다.  우리가 Controller에서 테스트할 내용은 다음과 같습니다. 

1. 원하는 url로 접근이 가능한지.
2. return되는 Model에 필요한 값이 존재하는지.
3. return된 Model의 값이 원하는 값으로 나오는지 확인

이 3가지가 되면 Controller는 테스트가 가능합니다. 그리고 View는 Controller에 의해서 나온 값을 보여주는 영역이기 때문에 특별히 테스트를 하지 않습니다. 최종적으로 View영역도 HTML의 테스트를 하는 것이 필요하지만, 이 부분은 지금 영역을 넘어가기 때문에 다루지 않도록 하겠습니다. 
이러한 테스트 방법으로 spring은 멋진 솔루션을 제공합니다. Controller에서 Ctrl+j를 눌러 Controller에 대한 단위 테스트 코드를 작성하도록 하겠습니다. 

@SuppressWarnings("unused")
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({ "file:src/main/webapp/WEB-INF/applicationContext.xml",  "file:src/main/webapp/WEB-INF/spring-servlet.xml"})
@WebAppConfiguration
public class HelloControllerTest {
    private MockMvc mvc;
    @Autowired
    WebApplicationContext context;

    @Before
    public void setUp() throws Exception{
        mvc = webAppContextSetup(context).build();
    }

    @Test
    public void getHello() throws Exception {
        MvcResult result = mvc.perform(get("/hello").param("name", "ykyoon"))
           .andExpect(status().isOk())
           .andReturn();
        String message = (String) result.getModelAndView().getModel().get("message");
        assertThat(message.contains("ykyoon"), is(true));
        assertThat(message, is(not(nullValue())));
        System.out.println(message);
    }
}

import를 엄청나게 많이 합니다.위 구성을 eclipse template에 등록하시면 좀 더 편하게 테스트 코드를 작성할 수 있습니다. 
그리고 테스트를 실행하면 너무나 깔끔하게 처리가 되는 것을 알 수 있습니다. 

test code 살펴보면 다음과 같습니다. 

먼저 MockMvc라는 servlet container를 가상으로 Spring 내부에서 만들어줍니다. 만들어지는 객체는 tomcat이나 jetty와 동일하게 움직입니다. 

mvc.perform method를 통해서 url을 기반으로 접근이 됩니다. 그리고, status값이 200이 나오는지 확인을 하는 구조로 만들어집니다. 
마지막으로 andReturn을 통해서 Model 과 View값을 얻어내 접근이 가능합니다. 이런 테스트 코드를 이용해서 우리가 만든 Controller가 정상적으로 움직이는지 확인이 가능합니다. 

다만, 이 테스트 코드는 Spring 3.2 이상에서만 가능합니다.; 그리고, web aplication에서의 테스트 코드는 우리가 실제로 사용할 aplicationContext.xml 을 그대로 사용하는 형식으로 테스트를 행해야지 됩니다. 
Controller의 테스트 코드는 매우 중요합니다. 지금은 단순하게 model의 값을 확인하는 것이지만, 후에 나올 Server 측 validation과 cookie의 만료 부분에서 이러한 테스트의 통과는 매우 중요한 역활을 갖게 됩니다.

지금까지 만든 코드는 Spring 2.x 대에서 Controller를 만드는 방법입니다. 그렇지만 이 부분은 약간의 논란이 있습니다. Spring의 장점인 특정 환경, 특정 기술에 종속되지 않는 코드의 기반이 깨지게 됩니다. Spring에서 제공하는 Controller interface를 반드시 상속을 해야지 되는 문제가 같이 발생하게 됩니다. 그리고, 코드와 URL간의 mapping이 xml에 있기 때문에 코드를 한번에 파악하기도 힘들게 됩니다. 그리고 가장 큰 문제는 전체 Url 1개 당 하나씩 객체가 만들어지고, 객체의 갯수는 기하급수적으로 계속해서 증가하게 되는 문제가 발생하게 됩니다.

그래서, 이 부분 문제를 해결하기 위해서 Spring 3.x에서는 다른 방법의 URL mapping을 지원하게 됩니다. 다음 장에서 Spring 3.x대에서의 URL mapping의 방법을 알아보도록 하겠습니다. 


web.xml 없는 spring mvc 설정 

web.xml 을 소개할 때 나왔던 web.xml이 없는 개발 방법에 대해서 알아보도록 하겠습니다. 
spring은 WebApplicationInitializer을 제공하고 있습니다. 이 interface는 javax.servlet.ServletContainerInitializer를 구현하고 있으며, Spring jar가 로드되면서 자동으로 web.xml 대신에 사용되도록 servlet container에 로드가 되게 됩니다. 
다음 코드를 먼저 확인해보도록 하겠습니다. 
먼저,  ControllerConfiguration을 한번 알아보도록 하겠습니다. 

@Configuration
public class Spring2WebConfiguration extends WebMvcConfigurerAdapter {
    @Bean
    public HelloSpring helloSpring() {
        return new HelloSpring();
    }

    @Bean(name="/hello")
    public HelloController helloController() {
        HelloController helloController = new HelloController();
        helloController.setHelloSpring(helloSpring());
        return helloController;
    }
}

그리고, WebAplicationInitializer를 구현한 Spring2WebApplicationInitializer 코드는 다음과 같습니다. 

public class Spring2WebApplicationInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(final ServletContext servletContext) throws ServletException {
        registerDispatcherServlet(servletContext);
    }

    private void registerDispatcherServlet(final ServletContext servletContext) {
        WebApplicationContext dispatcherContext = createContext(Spring2WebConfiguration.class);
        DispatcherServlet dispatcherServlet = new DispatcherServlet(dispatcherContext);
        ServletRegistration.Dynamic dispatcher = servletContext.addServlet("dispatcher", dispatcherServlet);
        dispatcher.setLoadOnStartup(1);
        dispatcher.addMapping("/app/*");
    }

    private WebApplicationContext createContext(final Class<?>... annotationClasses) {
        AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();
        context.register(annotationClasses);
        return context;
    }
}

이제 이 두 객체를 package에 넣고, web.xml을 없애거나 파일 이름을 변경시키면 자동으로 Spring2WebApplicationInitializer가 실행되게 됩니다. 

코드의 내용을 보시면, web.xml의 내용을 그대로 코드에 옮겨온것을 알 수 있습니다. dispatcherServlet을 등록시켜주고, dispatcherServlet에 Spring의 applicationContext bean들을 적용시켜주는 것으로 매우 쉽게 개발이 가능합니다. 
한번 jetty를 이용해서 /hello를 실행시켜보시길 바랍니다. 그리고 테스트 코드 역시 @ContextConfiguration에 classes 에 Spring2WebConfiguration.class만 등록시켜주시면 동일하게 사용 가능합니다. test나 개발에 있어서는 확실히 code base configuration이 좀 더 우위인것 같습니다.;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = Spring2WebConfiguration.class)
@WebAppConfiguration
public class HelloControllerTest {
    private MockMvc mvc;
    @Autowired
    WebApplicationContext context;



저작자 표시 비영리 변경 금지
신고
Posted by xyzlast Y2K

* 사내 강의용으로 사용한 자료를 Blog에 공유합니다. Spring을 이용한 Web 개발에 대한 전반적인 내용에 대해서 다루고 있습니다.


java로 개발한 application을 배포를 할때는 주로 jar, war 형태로 배포를 하게 됩니다. 
이 둘은 완전히 동일한 형식입니다. 다만, war는 web application을 배포하는 형식이고 jar는 library나 일반 application을 배포하는 형식입니다. 

Java Application의 배포



생성하지 않은 폴더와 파일이 있는 것을 알 수 있습니다. 
META-INF 폴더가 바로 그것인데요. 폴더 안에는 build시에 사용한 pom 파일을 비롯해서 MANIFEST.MF 파일이 있는 것을 알 수 있습니다. 이 파일은 다음과 같은 정보를 포함합니다. 

# Manifest-Version : Manifest file version
# Build-By : Build user
# Build-Jdk : jdk version
# Created-By : Build tool

이 내용은 jar파일에 대한 manual이나 스팩을 기록하는 폴더입니다. 그리고 우리가 web-resource와 같은 정적인 resource를 배포할 때도 역시 META-INF 폴더를 이용하게 됩니다. jar 파일은 자신이 개발한 class를 가질수도 있고, 심지어 jar에 jre까지 포함하는 것까지 가능합니다. 다른 jar 역시 추가하는 것도 가능합니다.

그리고, jar 형태로 구성이 되는 경우, ClassLoader에 의해서 로드되는 객체들은 jar의 root에 위치하게 됩니다. 이 부분은 war와 jar의 가장 큰 차이를 가지고 오게 됩니다. 

이제 packaging을 jar가 아닌 war로 packaging을 하는 경우를 알아보도록 하겠습니다. 
war 폴더 구조는 다음과 같습니다. 


war의 기본정보와 static-resource를 저장한 META-INF 폴더의 경우에는 jar와 동일하게 만들어집니다. 그리고 또다른 폴더가 하나더 생깁니다. WEB-INF 폴더가 바로 그것인데요. 이 폴더는 다음 2개의 폴더를 같이 포함합니다. 

# lib - 외부 및 추가 jar가 위치하는 폴더
# classes - 개발된 application의 compile된 class 파일이 위치

war의 경우에는 ClassLoader에 의해서 로드되는 객체들은 classes 폴더를 기준으로 로드가 이루어지게 됩니다.

그리고, 이 안에는 매우 중요한 파일이 하나 들어가게 됩니다. 그것은 web.xml인데요. java web application의 구성은 기본적으로 WEB-INF/web.xml 에서 결정됩니다. web.xml은 필터, 서블릿, DB소스 등  web container가 구동하는데 이용되는 환경설정파일입니다. 서버가 처음 로딩될때 web.xml파일을 읽어들여 해당 환경설정에 대해 어플리케이션 배치를 하게 됩니다. 다른 말로 web.xml은 배치 서술자(deployment de-scriptor)라고도 합니다. 

web.xml에 들어가는 환경설정은 다음과 같은 것들이 존재합니다.

1. 필터정보 (매핑 포함)
2. 서블릿정보 (매핑 포함)
3. 웹 애플리케이션 정보
4. 세션정보
5. 세션정보가 소멸, 생성, 수정되는 것을 알려주는 리스너 정보
6. MIME매핑
7. welcomefile정보
8. errorPage 정보
9. url보호 정보
10. 인터프라이즈 빈의 홈레퍼런스 정보 (로컬 레퍼런스 정보 포함)
가 있습니다. 

이 항목들에 대해서 각각 알아보도록 하겠습니다.

1. 필터 (filter)

필터는 요청이 들어오면 URL 패턴을 분석해서 해당 패턴의 요청이 들어오면 해당 요청에 담긴 정보들을 프로그래머가 원하는 형태의 데이터로 가공해서 서버로 요청을 넘길 수 있습니다. servlet과 비슷한 개념으로 계속 요청을 감시하고있습니다가 url패턴에 해당하는 요청이 들어오게되면 해당 요청을 가로채서 원하는 데이터 형태로 가공한뒤 다시 요청을 서버로 보내는 역할을 하게 됩니다.. 따라서 서버내에서 사용될 데이터 또는 화면으로 다시 보낼 데이터의 형태를 프로그래머가 원하는 형태로 단일화 시킬 수 있습니다.

<filter>
     <filter-name>myRequest</filter-name>
     <filter-class>myFilter.util.myReqFilter</filter-class>
     <init-param>
          <param-name>myRequestFilter</param-name>
          <param-value>filterTest</param-value>
     </init-param>
</filter>

필터 이름과 클래스, 초기화 파라미터를 지정하게 됩니다.. myRequest라는 필터는 myFilter.util 페키지 안에 있는 myReqFilter를 호출하며 초기화 파라미터로 myRequestFilter의 이름을 가진 filterTest값을 가지고 filter를 호출할것입니다. filter를 사용할때 사용할 클래스는 반드시 Filter인터페이스를 implenebts받아 doFilter메소드를 반드시 오버라이드 해주어야 하며 메소드 실행순서는 init() -> doFilter() -> destroy() 순으로 구성됩니다. 이는 Servlet의 생명 주기와 동일하게 동작합니다. 

<filter-mapping>
     <filter-name>myRequest</filter-name>
     <url-pattern>*.doFilter</url-pattern>
</filter-mapping>

위에서 선언한 filter정보를 url패턴과 매핑하는 부분입니다.
어떠한 URL의 확장자로 .doFilter가 함께 넘어오면 myRequest필터를 호출하게 되고 해당 필터는 myFilter.util 페키지안에 있는 myReqFilter 를 호출하게 됩니다. url-pattern 대신 servlet-name이 올 수 있습닌다.

servlet-name이 들어오게 되면 해당 패턴에 맞는 모든 filter가 실행되고 나서 servlet을 호출하게 됩니다..
filter는 여러겹으로 사용할 수 있는데 필터 체인(Filter Chain)이라는 용어로 쓰입니다.


2. 서블릿 (Servlet)

필터와 비슷한 맥락의 기능입니다. 그렇지만 큰 차이를 가지고 옵니다. Filter의 경우에는 Response와 Request에 대한 stream의 처리를 담당하고, 이에 대한 실질적인 Action을 담당하는 것이 Servlet입니다. web.xml에 매핑되어져 있는 서블릿들은 해당 요청을 포함하여 url패턴을 분석하고 거기에 매핑되어져 있는 클래스를 호출하여 처리를 하게 됩니다.
지정 방법은 다음과 같습니다.

<servlet>
     <servlet-name>loginServlet</servlet-name>
     <servlet-class>myServlet.util.loginServlet</servlet-class>
</servlet>

위처럼 하나의 서블릿 클래스를 생성해두고 해당 클래스를 servlet-class라는 element를 지정하게 됩니다..
나중에 loginServlet을 호출하면 myServlet.util 페키지 안에있는 loginServlet클래스가 호출될것입니다.

<servlet-mapping>
     <servlet-name>loginServlet</servlet-name>
     <url-pattern>*.login</url-pattern>
</servlet-mapping>

 
url패턴과 해당 해당 패턴에 해당하는 url로 접근시 호출될 servlet을 설정하는 부분입니다.
메타문자로 *가 올 수 있고 확장자를 설정하게 됩니다..
나중에 *.login이라는 URL을 서버로 요청하게되면 loginServlet의 이름을 가진 서블릿을 호출하게 됩니다..
해당 서블릿은 위에서 myServlet.util.loginServlet 클래스를 매핑해두었으므로 해당 클래스가 호출되는 형태가 될것입니다.

Spring은 이곳에 DispatcherServlet이라는 Spring에서 제공하는 Servlet을 이용해서 Spring MVC에서 Request를 처리합니다. 예를 들어 Naver의 경우에는 *.nhn 이라는 url-pattern에 DispatcherServlet을 연결시켜두는 것이 일반적입니다. 
인터넷 서핑을 주로 하시다보면 *.do url을 간간히 보게 되는데요. 이것은 Spring의 2.5대 버젼에서 Spring에서 추천하던 url-pattern입니다. web.xml의 설정의 경우에는 개발자들이 copy-paste 신공을 펼치는 경우가 많기 때문에 이것을 계속해서 이용하게 되는 경우도 많지요.

3. 웹 어플리케이션 정보 (Web Application )

웹 어플리케이션 정보를 설정하는 부분으로

<display-name>webApplication</display-name>
<description>desc for webApplication</description>

으로, Web Application의 정보와 표시 이름을 적을 수 있습니다. 


4. 세션정보 ( Session )

Session의 timeout 및 공유 방법을 결정할 수 있습니다. 

<session-config>
    <timeout>20</timeout>
    <shared>true</shared>
</session-config>


5. 세션 리스너 정보 ( Session Listner )
Session이 연결되고, 제거되는 각각의 event에 연결되는 Listner에 대한 정보를 기술할 수 있습니다. 아래는 servlet에서 기본으로 제공하는 listener입니다. 

javax.servlet.ServletContextAttributeListener
이 리스너는 컨텍스트에 저장된 애트리뷰의 변화가 있었을 때 설정된 이벤트를 엔진이 자동으로 발생시키도록 합니다. 이벤트 감지를 얻어내기 위해서는 여러분들이 직접 작성한 리스너의 implemention클래스를 통해야 하는것은 물론이며, 아래의 리스너 모두 동일하게 설정됩니다.

javax.servlet.ServletContextListener
당신이 작성한 웹애플리케이션에서 컨텍스트를 이용하여 무언가를 저장하고 이용할 수 있는데 이 리스너의 작동은 그러한 컨텍스트에 대한 변경이 이루어졌을 때 자동으로 엔진이 감지하고 작성한 클래스의 이벤트를 발생시킵니다.

javax.servlet.http.HttpSessionActivationListener
request.getSession(true)같은 경우처럼 Session에 대한 내용이 새로 생성되어 activate되어졌을 때 발생하는 이벤트를 감지하는 리스너입니다.

javax.servlet.http.HttpSessionAttributeListener
HttpSession에 대한 애트리뷰트의 변경시 연결되어지는 리스너입니다.

javax.servlet.http.HttpSessionBindingListener
HttpSession에 대하여 클라이언트 세션정보에 대한 바인딩이 이루어졌을 경우 감지되는 리스너입니다. 

이 SessionListener를 상속받아 구현된 class에 대한 정보를 web.xml에 다음과 같이 사용가능합니다. 

<listener>
    <listener-class>SessionListener</listener-class>
</listener> 


6. MIME 매핑 (MIME Mapping)
web server에서 보내지는 각각의 파일 리소스에 대한 정보를 mapping하는 영역입니다. 예를 들어 JSON의 경우 application/json 형태임을 web browser에게 알리는 등의 일을 수행합니다. 이것이 정상적으로 설정되어 있지 않으면 hwp와 같은 파일 포멧을 다운받지 못하고, browser에서 직접 열게 되는 식의 오동작을 발생시키게 됩니다. 아래와 같은 형식으로 설정이 가능합니다. 

    <mime-mapping>
        <extension>zip</extension>
        <mime-type>application/zip</mime-type>
    </mime-mapping>
    <mime-mapping>
        <extension>hwp</extension>
        <mime-type>application/unknown</mime-type>
    </mime-mapping>

7. welcomefile 정보 ( welcomeFile )
welcomeFile은 서버에 접속하면 가장 최초로 보여줄 파일을 지정하는 부분입니다.

  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>

서버를 구동한 후 http://localhost:8080/myWeb/ 로 접속을 하게되면 index.html이 실행될것입니다. html파일이 없다면 index.jsp가 실행됩니다.

8. errorPage 정보( ErrorPage )

특정 요청에 대해 error가 반환될때 해당 페이지를 보여주도록 설정이 가능합니다.

<error-page>
  <error-code>404</error-code>
  <location>/errors/404.jsp</location>
</error-page>
<error-page>
  <error-code>java.lang.NullPointerException</error-code>
  <location>/errors/badcode.jsp</location>
</error-page>


9. url보호 정보 ( URL Security )

로그인 및 각 URL에 대한 접근 정책을 결정할 수 있습니다.  이 때 사용되는 Security 정책은 servlet-container의 정책에 따르게 되기 때문에 Web Application에서 사용하기에는 조금 힘듭니다.
tomcat에서는 conf/tomcat-user.xml 에 사용자가 정의되어 있습니다.  tomcat manager에 등록되어 있는 default security 정책은 다음과 같습니다. 

<security-constraint>
  <display-name>Name String</display-name>
  <web-resource-collection>
    <web-resource-name>GETServlet</web-resource-name>
    <description>some description</description>
    <url-pattern>/servlet/*</url-pattern>
    <http-method>GET</http-method>
  </web-resource-collection>
  <auth-constraint>
    <description>some description</description>
    <role-name>*</role-name>
  </auth-constraint>
  <user-data-constraint>
     <description>some description</description>
     <transport-guarantee>INTEGRAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>
<login-config>
  <auth-method>FORM</auth-method>
  <realm-name>MemoryRealm</realm-name> 
  <form-login-config>
    <form-login-page>login.jsp</form-login-page>
    <form-error-page>notAuthenticated.jsp</form-error-page>
  </form-login-config>
</login-config>
<security-role>
  <description> some description</description>
  <role-name>administrator</role-name>
</security-role>


12. 인터프라이즈 빈의 홈레퍼런스 정보 (로컬 레퍼런스 정보 포함) ( Interprize Bean's Home Reference [Local Reference])

이제는 과거의 유산이 되어버린 ejb에 대한 설정 정보가 위치하는 곳입니다. ejb에 대한 정보 설정은 다음과 같이 설정됩니다.

<env-entry>
  <description>some description</description>
  <env-entry-name>MinimumValue</env-entry-name>
  <env-entry-value>5</env-entry-value>
  <env-entry-type>java.lang.Integer</env-entry-value>
</env-entry>
<ejb-ref>
  <description>some description</description>
  <ejb-ref-name>Employee Bean</ejb-ref-name>
  <ejb-ref-type>EmployeeBean</ejb-ref-type>
  <home>com.foobar.employee.EmployeeHome</home>
  <remote>com.foobar.employee.Employee</remote>
</ejb-ref>



web.xml 등록법

servlet의 변화에 따라 web.xml은 많은 확장이 있었습니다. web.xml의 정보는 다음 3가지 방법으로 표현될 수 있습니다. 

1. WEB-INF/web.xml 을 이용해서 등록하는 방법

가장 많이 사용되고 있으며, servlet 1.0부터 지금까지 구현된 방법입니다. 가장 대중적입니다. 

2. META-INF/web-fragment.xml 을 이용하는 방법

servlet 3.0 부터 지원되는 방법입니다. web.xml은 web application에 종속되는 방법입니다. web application 뿐 아니라, jar로 개발된 project에서 가지고 있는 META-INF 폴더 안의 web-fragment.xml을 이용해서 web을 구동하는 방법을 지원하고 있습니다. web-fragment.xml은 web.xml과 내용이 동일합니다. 이 방법이 나오게 된 이유는 Servlet 3.0에서부터는 web container를 포함한 설치형 war가 배포가 가능합니다. 지금까지는 web application을 tomcat과 같은 web container에 배포하는 것이 일반적이였지만, web container를 포함한 한개의 web application으로 구동하는 방법을 servlet 3.0에서 이제는 지원하고 있습니다.

3. javax.servlet.ServletContainerInitializer interface를 구현한 객체를 이용하는 방법

servlet 3.0 부터 지원되는 방법입니다. web.xml이 없이, application에서 작성한 ServletContainerInitializer를 구현하는 것으로 web.xml 대신 페이지를 작성할 수 있도록 지원하고 있습니다. 

3가지 방법중 3번의 방법이 조금 재미있습니다. ServletContainerInitializer를 구현한 객체를 이용하게 되면, 다음과 같은 설정들만 사용 가능합니다. 
* Listener 구성
* filter 구성
* Session Listener 구성
* ejb 구성

web.xml의 핵심이 구현되긴하지만, 자주 사용되는 다음 항목들이 제공되지 않습니다. 
* session-config
* error-page

이 두항목을 사용하기 위해서는 web.xml과 ServletContainerInitializer를 구현한 객체를 같이 사용해주면 됩니다. 그럼 ServletContainer는 web.xml을 먼저 로딩 후, 객체를 로드해서 사용하게 됩니다. 


저작자 표시 비영리 변경 금지
신고
Posted by xyzlast Y2K


티스토리 툴바