잊지 않겠습니다.

gradle 정리 - single project

Java 2013. 10. 25. 23:54
ava project에 대한 build tool의 최종 완성본

build tool의 역사

1. no build tool
2. ant
3. maven
4. gradle

Gradle을 이용한 java sample project의 개발

gradle setupBuild 를 이용한 초기 project build.gradle 파일 생성
기본적으로 maven way와 동일한 file path를 갖고 있다. 

src/main/java
src/main/resources
src/text/java
src/test/resources

1. targetCompatibility, sourceCompatibility의 설정
: 사용된 java version을 설정한다. 기본값은 1.5다

2. repositories의 설정
: repository를 설정한다. repository는 Maven에서 사용되던 것과 동일하며 Local PC에 maven이 설치된 경우, LocalPC에 대한 maven repository를 먼저 찾아보도록 설정하는 것이 가능하다. 
maven 설정은 다음과 같이 구성한다. 

repositories {
    mavenLocal()              //Local PC maven repository
    mavenCentral()           //mavenrepository site를 참조   
}

3. dependencies의 설정
: dependency를 설정한다. dependency의 경우에는 maven에 비하여 간결한 format을 지원한다.

 dependencies {

     compile 'org.slf4j:slf4j-api:1.7.5'
     testCompile "junit:junit:4.11"
     providedCompile 'javax.servlet:servlet-api:3.1'
     providedRuntime 'webcontainer:logging:1.0'
}


* compile : compile시에 필요한 dependency를 설정한다.

* testCompile : test 시에 필아한 dependency를 설정한다. 

* providedCompile : compile시에는 필요하지만, 배포시에는 제외될 dependency를 설정한다. (war plugin이 설정된 경우에만 사용 가능하다)

* providedRuntime : runtime시에만 필요하고, 실행환경에서 제공되는 dependency를 설정한다. (war plugin이 설정된 경우에만 사용 가능하다)

 

4. gradle build sequence

* compileJava : java compile

* processResources : resources로 지정된 file 처리 - jar를 만들기 위해 build folder로 copy등의 절차를 취한다

* classes : classes directory를 구성한다. compileJava를 통해 compile된 class객체와 resource들을 취합한다.

* jar : 모인 파일들을 이용해서 jar를 구성한다.

* compileTestJava : test code를 구성한다.

* processTestResources : test resources를 구성한다.

* testClasses : 앞 두과정을 통해서 모여진 파일들을 처리한다.

* test : testClass를 실행해서 JUnit/TextNG 결과를 도출시킨다.


Posted by Y2K
,

* 사내 강의용으로 사용한 자료를 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 Y2K
,
지금까지 우리는 View를 살펴봤습니다. 지금까지 본 View들은 File upload만을 제외하고, 사용자의 입력이 Controller단으로 전달되는 것이 전혀 없는 View입니다. 
기본적으로 Web은 URL을 통해서, 그리고 POST의 경우에는 Body에 실린 parameter를 통해서 값의 전달이 이루어지게 됩니다. 그리고, 이 값은 Controller를 통해서 전달됩니다. 
이제 Controller의 다른 기능인 사용자 Action을 받는 기능에 대해서 알아보도록 하겠습니다.  

다시 한번 기억하는 것으로 Controller의 기능은 두가지입니다. 

1. Client에게 View를 전달하는 주체
2. Client에서 데이터를 전달받는 주체

먼저, 아주 기본적인 HTML입니다. (Tiles를 사용해서 head 부분은 제거 되었습니다.)

<form method="post" class="example-form">
    <fieldset>Book</fieldset>
    <label>책 제목</label>        
    <input type="text" name="title" placeholder = "책 제목을 입력해주세요."/>
    <label>작가 이름</label>
    <input type="text" name="author" placeholder = "작가 이름을 넣어주세요."/>
    <label>추가 설명</label>
    <input type="text" name="comment" placeholder = "추가 설명을 넣어주세요."/>
    <br/>
    <button type="submit" class="btn">추가</button>
</form>


그리고, 이 form의 데이터를 받는 Controller의 action 코드는 다음과 같이 작성될 수 있습니다. 

    @RequestMapping(value = "/book/add01", method = RequestMethod.POST)
    public String add(String title, String author, String comment) {
        Book book = new Book();
        book.setTitle(title);
        book.setComment(comment);
        book.setAuthor(author);
        bookService.add(book);

        return "redirect:add01";
    }

값의 전달방법은 html의 element의 name이 각각의 parameter의 input으로 들어가게 됩니다. 이 부분의 코드를 보다 더 명확히 해준다면 다음과 같이 작성될 수 있습니다.

    @RequestMapping(value = "/book/add01", method = RequestMethod.POST)
    public String add(@RequestParam(value = "title") String title,
            @RequestParam(value = "author") String author,
            @RequestParam(value = "comment") String comment) {
        Book book = new Book();
        book.setTitle(title);
        book.setComment(comment);
        book.setAuthor(author);
        bookService.add(book);

        return "redirect:add01";
    }

입력값이 되는 title, author, comment를 보다더 명확하게 전달하게 되는 것을 볼 수 있습니다. 그런데, 이와 같은 개발 방법은 많은 코딩양을 가지고 오게 됩니다. 그리고, OOP 개발자들은 이렇게 생각할 수 있습니다.

"객체를 전달할 방법은 없을까?" 

다음과 같은 코드로서 말이지요. 

    @RequestMapping(value = "/book/add02", method = RequestMethod.POST)
    public String add02(Book book) {
        bookService.add(book);
        return "redirect:add01";
    }

Controller code만을 고치고, 테스트 코드를 이용해서 한번 알아보도록 하겠습니다.  값의 return 정상적으로 Book 객체가 생성이 되었는지를 알아보기 위해서 Controller 코드와 Test code를 잠시 수정했습니다. redirect시에는 model을 전달할 수 없기 때문에 redirect 시에 임시로 값을 저장하는 RedirectAttribute를 이용, FlashMap에 값을 저장하는 것으로 Controller code를 변경하였습니다. 변경된 결과와 테스트 코드는 다음과 같습니다. 

//BookController
    @RequestMapping(value = "/book/add02", method = RequestMethod.POST)
    public String add02(Book book, final RedirectAttributes redirectAttribute) {
        bookService.add(book);
        redirectAttribute.addFlashAttribute("book", book);
        return "redirect:add01";
    }
//BookControllerTest
    @Test
    public void add02() throws Exception {
        String bookTitle = "Book Title";
        String bookAuthor = "Book Author";
        String bookComment = "Book Comment";

        MvcResult mvcResult = mvc.perform(post("/book/add02")
                .param("title", bookTitle)
                .param("author", bookAuthor)
                .param("comment", bookComment))
                .andExpect(status().isFound())
                .andExpect(flash().attributeExists("book"))
                .andDo(print())
                .andReturn();
        
        Book book = (Book) mvcResult.getFlashMap().get("book");
        assertThat(book.getTitle(), is(bookTitle));
        assertThat(book.getComment(), is(bookComment));
        assertThat(book.getAuthor(), is(bookAuthor));
        
        System.out.println(mvcResult);
    }

예상대로 객체를 그대로 넘겨서 받을 수 있는 것을 알 수 있습니다. form을 통해서 데이터가 전달되게 되면 다음과 같은 형식으로 데이터가 전달되게 됩니다. 

title=BookTitle&author=BookAuthor&comment=BookComment

만약에 Controller에서 객체를 받게 된다면, property의 이름을 이용해서 값을 자동으로 연결(Bind)하게 됩니다. 이를 annotation을 통해서 보다 더 명확하게 적어주면 다음과 같은 코드로 표현될 수 있습니다. 

    @RequestMapping(value = "/book/add02", method = RequestMethod.GET)
    public String add02(Model model) {
        Book book = new Book();
        model.addAttribute("book", book);
        return "book/add02";
    }

    @RequestMapping(value = "/book/add02", method = RequestMethod.POST)
    public String add02(@ModelAttribute Book book, final RedirectAttributes redirectAttribute) {
        bookService.add(book);
        redirectAttribute.addFlashAttribute("book", book);
        return "redirect:add01";
    }


이 부분은 View에서 Controller에서 값이 전달되는 방법입니다. Form을 통해서 뿐 아니라 javascript를 이용한 ajax call 역시 같은 방법으로 데이터가 전달이 되게 됩니다. 이제 jquery를 통해서 값의 전달을 해보도록 하겠습니다. 

먼저 간단히 ajax에 대해서 알아보도록 하겠습니다. 

Ajax는 Synchronous JavaScript And XML(비동기 자바 스크립트와 XML)의 약자로 서버와의 비동기 통신을 이용해 마치 데스크탑 애플리케이션을 사용하는 것과 같은 사용자와 애플리케이션간의 인터랙티브한 사용자 경험을 가능하게 하는 스크립트 언어입니다.

이전의 동기 통신에서는 웹 애플리케이션이 서버와의 인터랙션을 필요로 할 때에 매번 브라우저가 사용자와의 인터랙션을 멈추고, 서버로부터의 응답이 올때까지 기다려야 했습니다. 서버로부터의 응답이 오기 전까지 사용자는 아무것도 할 수 없었죠.
하지만 비동기 통신에서는 서버로부터의 응답을 기다릴 필요 없이 사용자는 계속해서 애플리케이션에서 원하는 작업을 할 수 있습니다.

Ajax를 이용하는 예로는 구글맵, 검색사이트 검색창에서의 검색어 제시, 네이버 실시간 검색 순위 등이 있습니다.


Ajax의 장점

Ajax의 주요 장점은 아래와 같습니다.

1) 페이지 이동없이 고속으로 화면 전환
: Ajax는 페이지의 이전 없이 필요한 부분의 데이터 송수신만을 자유롭게 행할 수 있으므로, 효율적이고 빠르게 페이지를 전환할 수 있습니다.

2) 서버의 처리를 기다리지 않고 비동기 요청이 가능
: 서버와의 통신시 사용자는 서버로부터의 응답을 기다리지 않고 계속해서 다음 작업을 이어갈 수 있습니다.

3) 서버에서 처리하는 부분을 클라이언트에서 분담 가능
: Ajax로는 최소의 데이터만을 브라우저에 전달하기 위해 서버에서 하는 작업 중 JavaScript에서 수행 가능한 일을
클라이언트에서 분담하는 것이 가능합니다.

4) 수신하는 데이터의 양을 줄일 수 있음
: 기존의 브라우저가 수신하는 데이터는 HTML이나 XHTML과 같은 마크업 언어로 받는 것이 일반적인데 반해, Ajax로는 수신하는 데이터가 HTML이나 XML에 한정되지 않고 최소한의 텍스트 데이터로도 수신이 가능하기 때문에 수신 데이터이 양을 줄일 수 있습니다.

5) 실시간 인터렉티브 성능이 증가
: (1) ~ (4) 까지의 장점을 이용해 Ajax에서는 데스크탑 애플리케이션과 유사한 실시간 인터랙티브 성능을 보여줄 수 있습니다.

Ajax의 단점

Ajax의 단점은 아래와 같습니다.

1) 크로스 브라우저화의 노하우가 필요
: Ajax는 JavaScript 이므로 브라우저에 따른 크로스 브라우저 처리가 필요합니다.

2) Ajax를 지원하지 않는 브라우저에 대한 대책 필요
: Ajax를 지원하지 않는 브라우저에서는 사용이 불가능하므로 이에 대한 대책이 필요합니다. (하지만 현재 Ajax를 지원하지 않는 브라우저는 거의 없다고 볼 수 있습니다.)

3) 보안에 대한 주의가 불가피
: 페이지 이동 없이 서버와 통신하기 때문에 전보다 더욱 신중한 보안상의 주의가 요구됩니다.

4) 현재의 처리 상황에 대한 정보가 필요
: 페이지 전환 없이 처리가 진행되므로 사용자가 처리가 완료되었는데도 이를 모를 수 있습니다. 따라서 처리 중을 나타내는 프로그레시브 바등을 사용하는 것이 요구됩니다.

5) 요청을 남발하면 역으로 서버 부하가 늘 수 있음
: Ajax의 장점은 서버 부하의 감소에 있지만 그 의도와 반대로 요청이 너무 빈번하게 일어나 서버의 부하를 늘려버릴 수 있습니다. 따라서 데이터 전송량, 요청 회수, 서버 부하 등에 대한 종합적인 판단과 튜닝이 필요합니다.

6) Socket open / close의 부하 시간 증가
: 브라우저에서 가장 큰 부하를 주는 http call을 open을 자주 시키게 됩니다. URL이동으로 인하여 한번에 모든 데이터를 들고오는 방식을 ajax로 여러번을 나눠서 받는 경우, socket의 open/close 시간이 http call 횟수만큼 증가하게 됩니다. 적정한 ajax call이 필요합니다.

7) 개발의 어려움
: 1)항목과 연관이 있는 이야기입니다. javascript는 브라우져에 따라 동작이 다르게 움직여집니다. javascript를 테스트하기 위해서는 지금 상태로는 browser를 반드시 실행시켜서 그 결과를 확인해야지 됩니다. 상당한 수작업이 들어가기 때문에 ajax를 통해서 일을 진행을 해야지 된다면, 그에 대한 pattern등을 명확히 지정해야지 됩니다. 필요없이 모든 것을 다 ajax로 하게 되면 개발 시간뿐 아니라 부하역시 무시할 수 없기 때문입니다.


ajax의 장/단점을 한번 알아봤습니다. 아무리 단점이 있다고 해도, 기술적으로 가장 큰 장점인 비동기적 요청과 서버의 부하분산을 위해서 반드시 ajax는 사용해야지 됩니다. Book을 추가하는 code를 한번 ajax로 구현해보도록 하겠습니다. (기본적으로 jquery를 이용하도록 하겠습니다.)

다음은 html과 javascript입니다. 기존과 다른 점은 값의 전달을 form의 submit이 아닌 button에 event를 bind시켜서 사용하고 있다는 점입니다. 

<script>
$(function() {
  $('#add-button').on('click', function() {
      var title = $('form input[name=title]').val();
      var author = $('form input[name=author]').val();
      var comment = $('form input[name=comment]').val();
      addBook(title, author, comment);
  });
});

function addBook(title, comment, author) {
    $.post("add03", 
            {
                "title" : title,
                "author" : author,
                "comment" : comment
            }, 
            function(jsonResult){
                alert(jsonResult);
            }, 'json')
            .done(function(jsonResult) {
                console.log(jsonResult);
            })
            .fail(function(jsonResult) {
                console.log(jsonResult);
            });
            
}
</script>

<form method="post" class="example-form">
    <fieldset>Book</fieldset>
    <label>책 제목</label>        
    <input type="text" name="title" placeholder = "책 제목을 입력해주세요."/>
    <label>작가 이름</label>
    <input type="text" name="author" placeholder = "작가 이름을 넣어주세요."/>
    <label>추가 설명</label>
    <input type="text" name="comment" placeholder = "추가 설명을 넣어주세요."/>
    <br/>
    <button id="add-button" type="button" class="btn">추가</button>
</form>

다음은 Controller 코드입니다.

    @RequestMapping(value = "/book/add03", method = RequestMethod.GET)
    public String add03(Model model) {
        Book book = new Book();
        model.addAttribute("book", book);
        return "book/add03";
    }

    @RequestMapping(value = "/book/add03", method = RequestMethod.POST)
    @ResponseBody
    public Map<String, String> add03(@ModelAttribute Book book) {
        bookService.add(book);
        Map<String, String> bookDto = new HashMap<>();
        bookDto.put("title", book.getTitle());
        bookDto.put("author", book.getAuthor());
        bookDto.put("comment", book.getComment());

        return bookDto;
    }

기본적으로 json을 이용해서 book을 하나 insert 하게 되는 것을 볼 수 있습니다. 
지금까지 book을 추가하는 코드에 대해서 form을 이용하는 방법과 ajax를 이용하는 방법, 두가지 방법을 봤습니다. 하나 더 다른 내용을 보여드리겠습니다. 방금의 예시는 json을 이용해서 book에 대한 값을 다시 받아서 그 값을 이용해서 무언가 작업을 하는 것입니다. 만약에 paging을 해줘야지 되는 일이 발생한다면 이 것은 어떻게 처리를 해줘야지 될까요? 

2가지 방법이 있습니다. 

1. json을 만들어서 html 형식으로 문자열을 만든 다음에 특정 <div> section에 넣어주는 방법
2. Controller에서 html형식의 View를 return 시키고, 그 View를 특정 <div> section에 넣어주는 방법이 있습니다. 

이 두가지 방법에 대해서 알아보도록 하겠습니다. 

Ajax + JSON을 이용한 Paging

JSON을 이용해서 HTML을 만드는것은 HTML code 자체를 만드는 방법입니다. 먼저 Controller code를 살펴보도록 하겠습니다. 

    @RequestMapping(value = "book/list/index")
    public String getBookListIndex() {
        return "book/list/index";
    }

    @RequestMapping(value = "book/list/jsonpage", method = RequestMethod.POST)
    @ResponseBody
    public List<Book> getBookJsonList(@RequestParam(value = "pageIndex") int pageIndex,
            @RequestParam(value = "pageSize") int pageSize) {
        List<Book> books = bookService.listup(pageIndex, pageSize);
        return books;
    }

Controller는 2개의 method를 가지고 있습니다. 1개는 book list의 기본을 표시할 page이고, 2 번째 method는 book에 대한 json 값을 return 하는 method입니다. 이에 대한 HTML code를 살펴보도록 하겠습니다. 

<script type ="text/javascript">
$(function() {
    $('#btn-getbookList').on( 'click', function () {
        var pageIndex = parseInt($('input[name=pageIndex]' ).val());
        var pageSize = parseInt($('input[name=pageSize]' ).val());
        getBookList(pageIndex, pageSize);
    });
});

function getBookList(pageIndex, pageSize) {
    $.post("jsonpage", {
        pageIndex : pageIndex,
        pageSize : pageSize
    }, function(jsonResult) {
        var html = '<table class="table table-striped table-bordered table-hover">';
        for(var i = 0 ; i < jsonResult.length ; i++) {
            html += '<tr>';
            html += '<td>' + jsonResult[i].title + '</td>' ;
            html += '<td>' + jsonResult[i].author + '</td>' ;
            html += '<td>' + jsonResult[i].comment + '</td>' ;
            html += '</tr>';
        }
        html += '</table>';
        $( '#bookPage').html(html);       
    }, 'json');
}

</script>

<label>Page Index</label>
<input name ="pageIndex" type="number" />
<br/>
<label>Page Size</label>
<input name ="pageSize" type="number" value="3"/>
<br/>
<input type ="button" id="btn-getbookList" value="GetBookList"/>

<fieldset>
    <legend>Book List page </legend>
    <div id="bookPage" ></div>
</fieldset>

javascript를 이용해서 button에 click event를 bind시키고 있습니다. 그리고 getBookList function은 json을 통해서 얻어온 BookList의 숫자대로 loop를 돌아서 HTML code를 생성하는 것을 볼 수 있습니다. 최종적으로는 <table> 코드가 만들어져서 bookPagae라는 div tag에 추가 되는 형식으로 동작하게 됩니다. 


Ajax + HTML을 이용한 Paging

이 방법은 Controller에서 HTML View를 이용해서 보여지는 방법입니다. 서버단에서 View를 만들어주고, 그 View를 보여주는 방식으로 동작하게 됩니다. 이 View는 위 JSON으로 만들어지는 HTML과 완전히 동일한 HTML을 보내게 됩니다. 먼저 Controller 코드부터 살펴보도록 하겠습니다. 

    @RequestMapping( value = "book/list/index2" )
    public String getBookListIndex2() {
        return "book/list/index2" ;
    }

    @RequestMapping( value = "book/list/html" , method = RequestMethod.POST )
    public String getBookHtmlList( @RequestParam(value = "pageIndex") int pageIndex,
            @RequestParam(value = "pageSize") int pageSize ,
            Model model ) {
        List<Book > books = bookService. listup(pageIndex , pageSize);
        model.addAttribute ("books", books);
        return "book/list/html" ;
    }

Controller code는 매우 단순합니다. JSON으로 보내는것과 매우 유사합니다. 다만,  getBookHtmlList method에서 View name을 return 하는것만 다릅니다. book/list/html의 view code는 다음과 같이 구성됩니다.  view code는 바뀔 부분에 대한 HTML만을 보내게 됩니다. 

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
<%@ taglib prefix="tiles" uri="http://tiles.apache.org/tags-tiles" %>
<%@ page language= "java" contentType ="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

<table class ="table table-striped table-bordered table-hover">
<c:forEach var="book" items="${books } ">
    <tr>
        <td>${book.title }</td>
        <td>${book.author }</td>
        <td>${book.comment }</td>
    </tr>
</c:forEach>
</table>

위 javascript로 구성되는 html과 완전히 동일한 html을 만들것입니다. 이제 book/list/index2 view code를 살펴보도록 하겠습니다.

<script type="text/javascript">
$(function() {
    $('#btn-getbookList').on( 'click', function () {
        var pageIndex = parseInt($('input[name=pageIndex]' ).val());
        var pageSize = parseInt($('input[name=pageSize]' ).val());
        getBookList(pageIndex, pageSize);
    });
});

function getBookList(pageIndex, pageSize) {
    $.post("html", {
        pageIndex : pageIndex,
        pageSize : pageSize
    }, function(htmlResult) {
        $( '#bookPage').html(htmlResult);       
    });
}

</script >

<label>Page Index</label>
<input name ="pageIndex" type="number" />
<br/>
<label>Page Size</label>
<input name ="pageSize" type="number" value="3"/>
<br/>
<input type ="button" id="btn-getbookList" value="GetBookList"/>

<fieldset>
    <legend>Book List page </legend>
    <div id="bookPage" ></div>
</fieldset>

javascript에서 보내진 데이터를 그대로 div element에 집어넣은것 이외에는 차이가 없습니다. 


두 방법의 장,단점은 다음과 같습니다. 

방법장점단점
Ajax + JSON1. 데이터 전송량이 작다
2. client에서 html을 처리하기 때문에 server의 부하가 작다
1. javascript로 html을 만들어줘야지 되기 때문에 코드 작성에 어려움이 있다.
Ajax + HTML1. HTML + Server 코드이기 때문에 코드 작성이 간편하다

1. 데이터 전송량이 많다.
2. 서버에서 html rendering이 되기 때문에 server의 부하가 발생한다.


이 두 방법이 각각 장,단점을 가지고 있지만 어떤 방법이 더 우월하다고는 보기 힘듭니다. Ajax + HTML의 서버부하는 HTML cache를 통해서 충분히 해결이 될 수 있는 문제이고, javascript의 경우에도 구조화와 객체화를 통해서 충분히 쉬운 코드를 작성할 수 있습니다. 이것은 Style의 문제입니다. 그리고 개발에서 한가지 방법만을 정해두고 사용하기 보다는 주와 부를 나눠서 주는 Ajax + JSON으로 하고, javascript가 너무 복잡해지는 코드의 경우에는 Ajax + HTML로 구성하는것도 충분히 좋은 방법이라고 할 수 있습니다. 


Posted by Y2K
,

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


View는 다양한 방법으로 표현이 가능합니다. 지금까지 우리는 Html로만 표현되는 View를 알아봤습니다. 그럼 다른 Type의 View는 어떤 것들이 있을까요?

먼저, 가장 자주 쓰이는 Excel과 pdf가 있을수 있습니다. 그리고, json 형태로 표현되어서 다른 이기종간의 데이터 교환으로 사용될 수 있는 json format이 있을 수 있습니다.
마지막으로 View에서 넘길수 있는 특이한 형태로서, 파일을 upload를 알아보도록 하겠습니다. 

1. Excel

excel 파일을 생성하기 위해서는 apache poi jar가 필요합니다. apache poi는 microsoft office 파일을 다루기 위한 java open source library입니다. 
poi에서 다룰 수 있는 파일 종류는 다음과 같습니다. 

# Excel 
# Word
# PowerPoint
# Visio
# Outlook data file
# MS Publisher

2001년부터 시작된 오래된 java project 중 하나입니다. 참고 사이트는 다음과 같습니다. http://poi.apache.org/
poi를 사용하기 위해서 pom.xml에 다음 항목을 추가합니다. 

    <dependency>
      <groupId>org.apache.poi</groupId>
      <artifactId>poi</artifactId>
      <version>3.9</version>
    </dependency>
    <dependency>
      <groupId>net.sourceforge.jexcelapi</groupId>
      <artifactId>jxl</artifactId>
      <version>2.6.12</version>
    </dependency>

Excel 파일을 다루기 위해서는 org.springframework.web.servlet.view.document.AbstractJExcelView 를 상속받는 View를 구성해야지 됩니다. 이 View는 poi를 기반으로 구성이 되어 있으며, 다음 1개의 method만 재 정의하면 excel 파일을 작성할 수 있습니다.  

Spring에서는 Excel에 대해서 2개의 Abstract class를 제공하고 있습니다. AbstractJExcelView와 AbstractExcelView가 바로 그것입니다. 이 둘의 차이는 API의 사용 유무에 따라 다릅니다. JExcelView는 jexcelapi를 기반으로 구성되어 있으며, AbstractExcelView는 poi를 기반으로 구성되어 있습니다. 어느것이나 사용해도 좋지만, 좀 더 사용하기 편한 jexcelapi를 이용해보도록 하겠습니다.


    /**
     * Subclasses must implement this method to create an Excel Workbook
     * document, given the model.
     * @param model the model Map
     * @param workbook the Excel workbook to complete
     * @param request in case we need locale etc. Shouldn't look at attributes.
     * @param response in case we need to set cookies. Shouldn't write to it.
     * @throws Exception in case of failure
     */
    protected abstract void buildExcelDocument(Map<String, Object> model, WritableWorkbook workbook,
            HttpServletRequest request, HttpServletResponse response) throws Exception;

다음은 excel 파일을 만드는 View 코드입니다. 
public class BookExcelView extends AbstractJExcelView {
    @Override
    protected void buildExcelDocument(Map<String, Object> model, WritableWorkbook workbook, HttpServletRequest request, HttpServletResponse response)
            throws Exception {
        String fileName = createFileName();
        setFileNameToResponse(request, response, fileName);

        WritableSheet sheet = workbook.createSheet("책목록", 0);

        sheet.addCell(new Label(0, 0, "제목"));
        sheet.addCell(new Label(1, 0, "저자"));
        sheet.addCell(new Label(2, 0, "설명"));
        sheet.addCell(new Label(3, 0, "출판일"));

        @SuppressWarnings("unchecked")
        List<Book> books = (List<Book>) model.get("books");

        int row = 1;
        SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
        for (Book book : books) {
            sheet.addCell(new Label(0, row, book.getTitle()));
            sheet.addCell(new Label(1, row, book.getAuthor()));
            sheet.addCell(new Label(2, row, book.getComment()));
            sheet.addCell(new Label(3, row, dateFormat.format(book.getPublishDate())));
            row++;
        }
    }

    private void setFileNameToResponse(HttpServletRequest request, HttpServletResponse response, String fileName) {
        String userAgent = request.getHeader("User-Agent");
        if (userAgent.indexOf("MSIE 5.5") >= 0) {
            response.setContentType("doesn/matter");
            response.setHeader("Content-Disposition", "filename=\"" + fileName + "\"");
        } else {
            response.setHeader("Content-Disposition", "attachment; filename=\"" + fileName + "\"");
        }
    }

    private String createFileName() {
        SimpleDateFormat fileFormat = new SimpleDateFormat("yyyyMMdd");
        return new StringBuilder("책리스트").append("-").append(fileFormat.format(new Date())).append(".xls").toString();
    }
}

그리고 작성된 View는 생성의 비용을 줄이기 위해서 applicationContext에 다음과 같이 등록할 수 있습니다. 

<bean id="bookExcelView" class="com.xyzlast.mvc.bookstore.view.BookExcelView"/>

사용하는 Controller 코드는 다음과 같습니다. 
    @RequestMapping(value = "exceldownload", method=RequestMethod.GET)
    public ModelAndView downloadExcel() {
        List<Book> books = bookService.getAll();
        ModelAndView mv = new ModelAndView();
        mv.addObject("books", books);
        mv.setView(bookExcelView);
        return mv;
    }

Controller를 통해 다운 받은 Excel 파일은 다음과 같습니다. 



2. pdf - iText 2.x ~ 4.x

pdf 파일 포멧은 문서 포멧으로 가장 각광받는 포멧입니다. OS platform에 중립적인 문서 포멧으로 각광을 받고 있습니다. pdf 파일을 만들기 위해서는 iText가 필요합니다. 기본적으로 Spring은 iText 2.x대를 기반으로 구성이 되어있습니다. iText의 내용은 너무나 방대하기 때문에, http://itextpdf.com/book/ 를 참고해주시길 바랍니다. 
기본적으로 org.springframework.web.servlet.view.document.AbstractPdfView 객체를 상속받아서 pdf의 내용을 구현하는 것을 기본으로 하고 있습니다. 먼저, iText를 사용하기 위해서 다음 항목을 pom.xml에 추가합니다. 

<dependency>
    <groupId>com.lowagie</groupId>
    <artifactId>itext</artifactId>
    <version>2.1.7</version>
</dependency>


그리고, Pdf를 만들기 위한 View를 추가합니다. 
public class BookPdfView2 extends AbstractPdfView {

    @Override
    protected void buildPdfDocument(Map<String, Object> model, Document document, PdfWriter writer, HttpServletRequest request, HttpServletResponse response)
            throws Exception {
        String fileName = createFileName();
        setFileNameToResponse(request, response, fileName);

        Chapter chapter = new Chapter(new Paragraph("this is english"), 1);
        chapter.add(new Paragraph("이건 메세지입니다."));
        document.add(chapter);
    }

    private void setFileNameToResponse(HttpServletRequest request, HttpServletResponse response, String fileName) {
        String userAgent = request.getHeader("User-Agent");
        if (userAgent.indexOf("MSIE 5.5") >= 0) {
            response.setContentType("doesn/matter");
            response.setHeader("Content-Disposition", "filename=\"" + fileName + "\"");
        } else {
            response.setHeader("Content-Disposition", "attachment; filename=\"" + fileName + "\"");
        }
    }

    private String createFileName() {
        SimpleDateFormat fileFormat = new SimpleDateFormat("yyyyMMdd_HHmmss");
        return new StringBuilder("설문조사").append("-").append(fileFormat.format(new Date())).append(".pdf").toString();
    }
}

buildPdfDocument를 override 시켜서 문서를 만드는것을 확인해주세요. Controller에서 사용하는 방법은 Excel과 동일하기 때문에 생략하도록 하겠습니다. 꼭 한번 해주시길 바랍니다. 이 코드에는 심각한 버그가 하나 있습니다. ^^


3. pdf - iText 5.x


위에 소개드린것처럼 기본적으로 Spring은 2.x대의 iText를 기반으로 구성되어 있습니다. 그렇지만, iText 5.x대를 사용하도록 View 인터페이스를 구현하면 iText 5.x대의 버젼을 사용할 수 있습니다. iText 5.x를 이용한 새로운 View를 만들어보도록 하겠습니다. 
먼저, iText 5.x를 추가하기 위해서 pom.xml에 다음 설정을 추가합니다. 

<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>itextpdf</artifactId>
    <version>5.4.0</version>
</dependency>


iText가 버젼업이 되면서 가장 문제가 되는 것은 package 명이 변경되었다는 점입니다. 사용되는 객체들의 이름은 변경된 것이 없지만, 전체 package 명이 바뀌면서 기존의 AbstractPdfView를 사용할 수가 없게 되어버렸습니다. 새로운 View를 만들어서 iText5를 지원할 수 있도록 해봅시다. 
View를 새로 만들어줄 때는 Spring에서 제공하는 AbstractView를 상속받아서 처리하는 것이 일반적입니다. IText5를 지원하기 위해서, AbstractIText5PdfView 객체를 생성했습니다. 
override된 다음 method들을 살펴볼 필요가 있습니다. 

    protected boolean generatesDownloadContent();
    protected final void renderMergedOutputModel(Map<String, Object> model, HttpServletRequest request, HttpServletResponse response) throws Exception;
    protected void writeToResponse(HttpServletResponse response, ByteArrayOutputStream baos) throws IOException;

# generatesDownloadContents
Download가 이루어질 View인지, 아니면 Html과 같이 Rendering될 View인지를 결정하는 method입니다. true/false로 설정하면됩니다.

# renderMergedOutputModel
실질적으로 View가 생성되는 코드입니다. 여기에서는 iText를 이용한 pdf document를 생성하는 코드가 위치하게 됩니다.

# writeToResponse
HttpResponseServlet에 output을 보내는 코드입니다. 

만들어진 AbstractIText5PdfView의 전체 코드는 다음과 같습니다.

public
abstract class AbstractIText5PdfView extends AbstractView { public AbstractIText5PdfView() { setContentType("application/pdf"); } @Override protected boolean generatesDownloadContent() { return true; } @Override protected final void renderMergedOutputModel(Map<String, Object> model, HttpServletRequest request, HttpServletResponse response) throws Exception { ByteArrayOutputStream baos = createTemporaryOutputStream(); Document document = newDocument(); PdfWriter writer = newWriter(document, baos); prepareWriter(model, writer, request); buildPdfMetadata(model, document, request); document.open(); buildPdfDocument(model, document, writer, request, response); document.close(); writeToResponse(response, baos); } @Override protected void writeToResponse(HttpServletResponse response, ByteArrayOutputStream baos) throws IOException { response.setContentType(getContentType()); ServletOutputStream out = response.getOutputStream(); baos.writeTo(out); out.flush(); } protected Document newDocument() { return new Document(PageSize.A4); } protected PdfWriter newWriter(Document document, OutputStream os) throws DocumentException { return PdfWriter.getInstance(document, os); } protected void prepareWriter(Map<String, Object> model, PdfWriter writer, HttpServletRequest request) throws DocumentException { writer.setViewerPreferences(getViewerPreferences()); } protected int getViewerPreferences() { return PdfWriter.ALLOW_PRINTING | PdfWriter.PageLayoutSinglePage; } //Document가 open되기 전, pdf의 meta 정보를 넣을 때 사용 protected abstract void buildPdfMetadata(Map<String, Object> model, Document document, HttpServletRequest request) throws Exception; //pdf의 내용을 추가하는데 이용 protected abstract void buildPdfDocument(Map<String, Object> model, Document document, PdfWriter writer, HttpServletRequest request, HttpServletResponse response) throws Exception; }


여기에서 중요한 method는 buildPdfMetaData와 buildPdfDocument method입니다. 

# buildPdfMetadata
Pdf 문서의 정보를 지정할 수 있는 method입니다. 이때는 pdf document가 아직 open이 되지 않은 상태이기 때문에, 문서에 내용을 추가하거나 만드는 것이 아닌 문서 자체의 정보를 기록하게 됩니다. 이 method에서 할 수 있는 중요한 일은 암호화와 권한을 설정할 수 있습니다. 이 부분에 대해서는 watermark를 지원하는 pdf 또는 pdf security 부분을 참조해주시면 될 것 같습니다. 

# buildPdfDocument
Pdf 문서를 작성하는 method입니다. pdf document를 작성하는 실질적인 method입니다. IText 2.x를 지원하는 View와 동일한 코드를 작성해주면 됩니다.

아래는 만들어진 AbstractIText5PdfView를 상속받아서 구현된 BookPdfView입니다. 

public class BookPdfView extends AbstractIText5PdfView {
    @Override
    protected void buildPdfDocument(Map<String, Object> model, Document document, PdfWriter writer, HttpServletRequest request, HttpServletResponse response)
            throws Exception {
        String fileName = createFileName();
        setFileNameToResponse(request, response, fileName);
        Chapter chapter = new Chapter(new Paragraph("this is english"), 1);
        chapter.add(new Paragraph("이건 메세지입니다."));
        document.add(chapter);
    }

    private void setFileNameToResponse(HttpServletRequest request, HttpServletResponse response, String fileName) {
        String userAgent = request.getHeader("User-Agent");
        if (userAgent.indexOf("MSIE 5.5") >= 0) {
            response.setContentType("doesn/matter");
            response.setHeader("Content-Disposition", "filename=\"" + fileName + "\"");
        } else {
            response.setHeader("Content-Disposition", "attachment; filename=\"" + fileName + "\"");
        }
    }

    private String createFileName() {
        SimpleDateFormat fileFormat = new SimpleDateFormat("yyyyMMdd_HHmmss");
        return new StringBuilder("pdf").append("-").append(fileFormat.format(new Date())).append(".pdf").toString();
    }

    @Override
    protected void buildPdfMetadata(Map<String, Object> model, Document document, HttpServletRequest request) throws Exception {
        //Meta data 처리는 하지 않습니다.
    }
}

만들어서 사용해보면 이상한점을 발견할 수 있습니다. 영어 메세지는 표시가 되지만, 한글 메세지는 표시가 되지 않습니다. 그건 기본적으로 pdf가 영문 font만을 사용하도록 문서가 구성이 되어있기 때문입니다. pdf에서 영문 이외의 한글/한문/일어 를 보기 위해서는 itext-asian이라는 library를 추가로 사용해야지 됩니다. 

<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>itext-asian</artifactId>
    <version>5.2.0</version>
</dependency>

library를 추가를 하고, BookPdfView의 buildPdfDocument를 다음과 같이 수정하도록 합니다. 
    @Override
    protected void buildPdfDocument(Map<String, Object> model, Document document, PdfWriter writer, HttpServletRequest request, HttpServletResponse response)
            throws Exception {
        String fileName = createFileName();
        setFileNameToResponse(request, response, fileName);
        BaseFont cfont = BaseFont.createFont("HYGoThic-Medium", "UniKS-UCS2-H", BaseFont.NOT_EMBEDDED);
        Font objFont = new Font(cfont, 12);

        Chapter chapter = new Chapter(new Paragraph("this is english"), 1);
        chapter.add(new Paragraph("이건 메세지입니다.", objFont));
        document.add(chapter);
    }

한글 font를 지정하고, 그 Font를 사용하는 것을 볼 수 있습니다. 실질적으로 itext-asian은 java code가 하나도 없는 jar 파일입니다. 내부는 Font에 대한 meta data들만 추가되어 있는 상태에서 그 Font를 사용하도록 설정을 조금 변경시킨 것 밖에는 없습니다. 
다음은 만들어진 pdf 파일입니다. 




4. Json

json은 web api의 데이터 Protocol로 주로 사용됩니다. HTML과 atom은 xml을 base로 한 문서용 마크업언어입니다. 그런데, 이 형태는 데이터를 기술하기에는 표기가 너무나 중복이 됩니다. 그래서, 좀 더 단순한 데이터의 포멧이 제안되었고, 그 중에서 가장 각광받고, 자주 사용되고 있는 것이 json format입니다. 
지금 Book 객체에 대한 json 은 다음과 같이 표현됩니다. 

{
  • id335,
  • title"Changed Title > Title : 8",
  • authornull,
  • comment"Changed Comment : Comment : 8",
  • publishDate1362641616000,
  • createDate1362641616000,
  • updateDate1362641616000,
  • status"MISSING",
  • imageUrlnull,
  • rentUser:  {
    • id329,
    • loginId"User Id 8",
    • name"Name 8",
    • password"Password 8",
    • checkSum3069349407,
    • lastLoginTime1362641616000,
    • joinTime1362641616000,
    • pointnull,
    • levelnull,
    • histories: [ ]
    }
},

xml보다 간단한 표시 방법에, 다양한 데이터를 표현할 수 있어서 자주 사용되는 데이터 포멧입니다. 기술적으로는 다음과 같은 장점을 갖습니다. 

1) 데이터의 사이즈가 xml보다 작기 때문에 network 부하가 작습니다.
2) javascript에서 처리가 매우 간단합니다. 
3) 사용하기 쉽고, 직관적입니다. 

java에서 json data format으로 객체를 변경시키는 library는 jackson, gson 등 다양한 library 들이 존재합니다. spring에서는 jackson을 json default converter로 이용합니다. jackson에 대한 jar 설정을 pom.xml에 추가합니다. 

    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-core</artifactId>
      <version>2.1.4</version>
    </dependency>
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>2.1.4</version>
    </dependency>
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-annotations</artifactId>
      <version>2.1.4</version>
    </dependency>

또한, messageConvert에 jackson을 사용하도록 spring의 request adapter를 수정해야지 됩니다. 

그리고, controller에 book list를 jackson으로 얻어내는 method를 추가하도록 하겠습니다. 기본적으로 categories, histories는 json으로 얻어낼 필요가 없다고 생각되어서 이 두개의 property를 제외했습니다. 또한 user역시 histories를 얻을 필요가 없어서 property를 제거하도록 하겠습니다. jackson으로 변환되지 않기를 원하면 @JsonIgnore annotaion을 붙여 사용하면 됩니다. 변경된 Book 입니다.

@Entity
@Table(name="books")
public class Book {
    @Id
    @Column(name="id")
    @GeneratedValue(strategy=GenerationType.AUTO)
    private long id;
    @Column(name="title", length=255)
    private String title;
    @Column(name="author", length=255)
    private String author;
    @Column(name="comment", length=255)
    private String comment;
    @Column(name="publishDate")
    private Date publishDate;
    @Column(name="createDate")
    private Date createDate;
    @Column(name="updateDate")
    private Date updateDate;
    @Column(name="status")
    @Enumerated(EnumType.ORDINAL)
    private BookStatus status;
    @Column(name="imageUrl")
    private String imageUrl;
    @ManyToOne
    @JoinColumn(name="rentUserId", nullable=true)
    private User rentUser;
    @JsonIgnore
    @ManyToMany
    @JoinTable(name="books_categories",
               joinColumns = {@JoinColumn(name="bookId")},
               inverseJoinColumns = {@JoinColumn(name="categoryId")}
            )
    private Set<Category> categories = new HashSet<>();
    @JsonIgnore
    @OneToMany(mappedBy="book")
    private Set<History> histories = new HashSet<>();;

그리고, Controller에 다음 method를 추가합니다. 

    @RequestMapping(value="list/json", method=RequestMethod.GET)
    @ResponseBody
    public List<Book> listup() {
        return bookService.getAll();
    }

마지막으로 테스트코드를 통해서 json output이 정상적으로 되는지 확인해보도록  합니다.

    @Test
    public void listupJson() throws Exception {
        MvcResult result = mock.perform(get("/book/list/json")).andExpect(status().isOk()).andReturn();
        System.out.println(result.getResponse().getContentAsString());
    }

그리고 위와 같이 Entity를 바로 넘기게 되는 순환 참조 오류를 해결하기 위해서 다른 DTO를 생성해서 그 DTO를 넘겨주기도 합니다. 간단히 Map 객체를 만들어서 넘기는 Controller 코드는 다음과 같습니다.

    @RequestMapping(value = "book/json")
    @ResponseBody
    public Object convertToJson() {
        List<Book> books = bookService.listup();
        List<Map<String, Object>> maps = new ArrayList<>();

        for (Book book : books) {
            Map<String, Object> item = new HashMap<>();
            item.put("title", book.getTitle());
            item.put("comment", book.getComment());
            maps.add(item);
        }
        return maps;
    }

Controller에서 @ResponseBody를 처음 사용해봤습니다. @ResponseBody는 따로 View를 갖지 않고, html body 자체에 output을 적는 방법입니다. web api를 사용하는 경우에는 대부분 이러한 방법으로 output을 처리합니다. json에 대해서는 자주 사용되기 때문에 꼭 사용법을 익혀두시길 바랍니다.

5. File upload

File upload는 View가 아닙니다. 이번 장에서 설명하는 영역으로 약간 부적절한 면이 있긴 하지만 이 부분은 Controller 영역입니다. Spring에서 제공하는 HttpRequestServlet이 보내는 Multipart file upload 데이터를 Handling하는 방법을 소개하도록 하겠습니다. Multipart file upload를 처리하기 위해서는 다음 jar들이 필요합니다. 

    <dependency>
      <groupId>commons-fileupload</groupId>
      <artifactId>commons-fileupload</artifactId>
      <version>1.2.2</version>
    </dependency>
    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
      <version>2.4</version>
    </dependency>

먼저, file을 upload하기 위해서는 반드시 다음과 같은 설정이 applicationContext.xml에 위치해야지 됩니다. 

  <bean id="multipartResolver"
    class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
    <property name="maxUploadSize" value="2000000" />
  </bean>
  <bean id="uploadDirResource" class="org.springframework.core.io.FileSystemResource">
    <constructor-arg>
      <value>C:/upload/</value>
    </constructor-arg>
  </bean>

위 설정은 매우 민감한 설정입니다. bean의 id도 무조건 multipartResolver라는 이름으로 지정이 되어야지 되며, uploadDirResource 역시 bean의 id가 고정되어야지 됩니다. 이 id를 바꿔주는 것은 불가능합니다. 각 bean들은 file upload의 max size와 저장될 위치를 결정하게 됩니다. 반드시 bean id를 위 설정과 동일하게 설정해야지 된다는 것을 잊지 말아주세요. 

upload 할 데이터에 대한 dto를 만들어줍니다. 이 dto 객체는 Request에서 오는 http 데이터를 Controller로 전달하는 역활을 담당하게 됩니다. 

public class UploadItem {
    private String name;

    private CommonsMultipartFile fileData;

    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public CommonsMultipartFile getFileData() {
        return fileData;
    }
    public void setFileData(CommonsMultipartFile fileData) {
        this.fileData = fileData;
    }
}

CommonsMultipartFile 객체를 property로 갖는 것을 확인해보실 수 있습니다. 이제 이 객체와 mapping되는 Html 을 구성하도록 하겠습니다. 
기본적으로 Spring @MVC에서 form을 통한 데이터 전달을 할때는 form안에 위치한 input tag의 이름과 property의 이름간에 1:1로 mapping이 되게 됩니다. UploadItem DTO는 아래와 같은 Html과 mapping이 될 수 있습니다. file upload를 하기 위해서 enctype이 multipart/form-data로 되어있는 것을 확인하시길 바랍니다.

<%@ 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>Upload Example</title></head><body>
    <form name="uploadItem" method="post" enctype="multipart/form-data">
        <fieldset>
            <legend>Upload Fields</legend>
            <p>
                <label for="name-id">Name</label>
                <input type="text" id="name-id" name="name" />
            </p>
            <p>
                <label for="fileData-id">파일 업로드</label>
                <input type="file" id="fileData-id" name="fileData" type="file" />
            </p>
            <p>
                <input type="submit" />
            </p>
        </fieldset>
    </form></body></html>



이제 이 form data를 받아올 Controller code를 알아보도록 하겠습니다. 지금까지 데이터를 form이나 url을 통해서 언제나 int, String 형태로만 받아오던 데이터를 이제는 DTO를 통해서 받아보도록 하겠습니다. 

    @RequestMapping(value="index", method=RequestMethod.POST)
    public String uploadCompleted(UploadItem uploadItem, BindingResult result) {
        if (result.hasErrors()) {
            for (ObjectError error : result.getAllErrors()) {
                System.err.println("Error: " + error.getCode() + " - " + error.getDefaultMessage());
            }
            return "upload/uploadForm";
        }

        if (!uploadItem.getFileData().isEmpty()) {
            String filename = uploadItem.getFileData().getOriginalFilename();
            String imgExt = filename.substring(filename.lastIndexOf(".") + 1, filename.length());

            // upload 가능한 파일 타입 지정
            if (imgExt.equalsIgnoreCase("JPG") || imgExt.equalsIgnoreCase("JPEG") || imgExt.equalsIgnoreCase("GIF")) {
                byte[] bytes = uploadItem.getFileData().getBytes();
                try {
                    File outFileName = new File(fsResource.getPath() + "_" + filename);
                    FileOutputStream fileoutputStream = new FileOutputStream(outFileName);
                    fileoutputStream.write(bytes);
                    fileoutputStream.close();
                } catch (IOException ie) {
                    System.err.println("File writing error! ");
                }
                System.err.println("File upload success! ");
            } else {
                System.err.println("File type error! ");
            }
        }

받아온 데이터를 이용해서 file을 저장할 수 잇는 것을 알 수 있습니다. 그런데, 지금까지보던 Controller의 input값과는 조금 다른 값이 보입니다. BindingResult가 그 결과인데요. BindingResult는 Request에서 보내지는 응답을 DTO로 변환하게 될 때, 변환과정에서 에러가 발생하는지를 확인하는 객체입니다. 그리고 Request가 DTO로 변환하는 과정을 Binding이라고 합니다. 


Summay

지금까지 5개의 Controller Action에 대해서 알아봤습니다. 

# excel
# pdf (iText 2.x)
# pdf (iText 5.x) - AbstractView를 이용한 신규 View의 생성
# json
# file upload

이 부분에 대해서 직접 돌아가는 web page를 한번 만들어보시길 바랍니다. 그리고 그 동작이 어떻게 일어나는지 확인하는 것이 이쪽까지의 과제입니다. 
다음은 오늘 잠시 나왔던 Binding에 대해서 좀 더 알아보도록 하겠습니다.


Posted by Y2K
,

23. View의 표현법 - HTML

Java 2013. 9. 13. 08:33

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


크게 View는 Html을 표시시키는 View와 Application을 이용할 때 사용되는 View. 두개로 나눌수 있습니다. 이번 장에서는 Html을 표시하는 View를 알아보도록 하겠습니다.

1. JSP & JSTL

jsp와 jstl을 사용하기 위해서는 특별한 View 설정은 필요없지만, 기본적으로 Spring에서 요구되는 View는 WEB-INF 폴더 안에 view file들을 위치시키고, client에서 직접 접근할 수 없도록 하는 것이 일반적입니다. 이때는 기본적으로 InternalResourceViewResolver를 사용해서 View 파일의 위치를 설정하도록 합니다.

  <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
    <property name="prefix" value="/WEB-INF/views/" />
    <property name="suffix" value=".jsp" />
    <property name="contentType" value="text/html; charset=UTF-8" />
    <property name="order" value="1" />
  </bean>

code base로는 다음과 같이 설정하면 됩니다. 
    @Bean
    public UrlBasedViewResolver viewResolver() {
        UrlBasedViewResolver jspViewResolver = new UrlBasedViewResolver();
        jspViewResolver.setOrder(4);
        jspViewResolver.setPrefix("/WEB-INF/view/");
        jspViewResolver.setSuffix(".jsp");
        jspViewResolver.setContentType("text/html; charset=UTF-8");
        jspViewResolver.setViewClass(JstlView.class);
        return jspViewResolver;
    }

jsp만으로는 제어문을 구성할 수 없기 때문에 jstl을 이용해서 jsp를 확장해야지 됩니다. jstl을 사용하기 위해서는 pom.xml에 다음 항목을 추가해주세요.

        <dependency>
            <groupId>jstl</groupId>
            <artifactId>jstl</artifactId>
            <version>1.2</version>
        </dependency>

JSTL은 다양한 tag를 지원하고 있습니다. 이는 기존 jsp에서 <%= %>에서 빈번하게 만들어지는 code들을 단순화하고 읽기 편한 간단한 언어로 만들기 위해서 제공되고 있습니다.  jsp는 다음과 같은 tag를 선언함으로서 사용할 수 있습니다. 

<%@taglib prefix="c"uri="http://java.sun.com/jsp/jstl/core"%>

1) c:out  - 객체를 출력한다.
<!--기본 문법--><c:out value="${name}"/><!--  default 속성 : 값이 없을때 기본출력값을 정의-->
<c:out value="${age}" default="Null or empty"/> 
<!-- escapeXml 속성 : 기본적으로 XML 문자를 escape하는데 Escape 하지 않으려면  false로 설정-->
<c:out value="${name}" escapeXml="false"/>

2) c:set  - 객체를 저장(셋팅)한다.
<!--기본문법-->
<c:set var="name" value="홍길동" /><!--Scope 속성 : page | request | session | application 중 1개의 값 page가 기본값-->
<c:set scope="request" target="book" property="isbn" value="300"/><!--target,property속성:  홍길동의 값을 UserModel 객체의 UserName 프로퍼티값을 설정 -->
<c:set value="홍길동" target="UserModel" property="UserName"/>

3) c:remove - 객체를 삭제한다.
<!--기본문법-->  
<c:remove  var="name" scope="request" />  

4) c:if - 조건문
<!--기본문법-->  
<c:if test="${조건}">  
    조건 만족시 이 영역을 수행  
</c:if>  

jstl에서 if문은 조금 문제가 있습니다. 그건 else가 존재하지 않는 문제인데요. 우리가 주로 사용하는 if~else 문을 갖추기 위해서는 아래의 choose문을 사용해야지 됩니다.

5) c:choose, c:when, c:otherwise - switch 문이라 생각하면된다.
<!--기본문법-->   
<c:choose>  
    <c:when test="${value == 1}">  
        value가 1이면 이 영역을 수행  
    </c:when>  
    <c:when test="${value == 2}">  
        value가 2이면 이 영역을 수행  
    </c:when>  
    <c:otherwise>  
        value가 1,2가 아니면 이 영역을 수행(기본값)  
    </c:otherwise>  
</c:choose>  

6) c:foreach - 반복문
<!--기본문법(0~9까지 출력)-->   
<c:forEach begin="0" end="9" var="i">  
    <c:out value="${i}"/>  
</c:forEach>  
<!-- step 속성 : 정의된 수만큼 증가를 시킨다.(1,3,5,7,9출력)-->  
<c:forEach var="test" begin="1" end="10" step="2" >  
     <b>${test }</b>   
</c:forEach>  

7) c:forTokens - 구분자로 반복문
<!--기본문법(변수를 ','로 구분하여 출력한다. )-->   
<c:forTokens var="alphabet" items="a,b,c,d,e,f,g,h,i,j,k" delims="," varStatus="idx" >  
     <b>${alphabet }</b>  
</c:forTokens>  


8) c:url, c:param  - URL을 처리
<!--기본문법-->   
<c:url value="index.jsp"/>  
<!-- value의 속성값이 /로 시작하면 컨텍스트를 포함한다-->  
<!--Context가 Root이라면 /Root/index.jsp로 출력-->  
<c:url value="/index.jsp"/>  
<!--context 속성 : 다른 컨텍스트로 출력하고자할때 사용-->  
<!-- /newRoot/index.jsp로 출력-->  
<c:url value="/index.jsp" context="/newRoot"/>  

9) c:import - JSP파일을 인클루드한다.
<!-- 기본 문법 -->  
<!-- partialView.jsp의 내용을 출력 -->  
<c:import url="partialView.jsp"/>  
<!-- charEncoding 속성:   인코딩에 문제가 있을 시 사용 -->  
<c:import url="UserForm.jsp" charEncoding="UTF-8"/>  

10) c:redirect - 리다이렉션
<!-- 기본 문법 -->  
<c:redirect url="http://kkams.net"/>  


11) c:catch - 예외 발생시 처리
<!-- 기본 문법 -->  
<c:catch var="err">    
    <%=10 / 0%> <!--0으로 나누면 에러 발생-->  
</c:catch>  
<!--에러 출력-->  
<c:out value="${err }" />  


다양해보이지만, 상당히 빈약한 문법과 코드를 가지고 있는 것이 JSTL입니다. 자주 사용되기도 하고, 일단 표준이기 때문에 몰라서는 안되는 View 표현 방법입니다. 앞서 Controller에서 보내지는 Model의 값을 JSTL을 이용해서 표현하게 되는 것이 일반적입니다. 

지금까지 본 jstl을 이용한 book list의 표현과 book add의 표현방법입니다. 

    @RequestMapping("book/list")
    public String listup(Model model) {
        List<Book> books = bookService.listup();
        model.addAttribute("books", books);
        return "book/list";
    }

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags"%>
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form"%>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions"%>
<%@ 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>
<link href="/res/css/bootstrap.min.css" rel="stylesheet" />
<link href="/res/css/sample.css" rel="stylesheet" />
<script src="/res/js/bootstrap.min.js"></script>
</head>
<h2>jstl test code 입니다.</h2><div class="example-form">
    <h3>c:forEach example code</h3>
    <spring:message code="code.message"></spring:message>
    <table class="table table-striped table-bordered table-hover">
        <thead>
            <tr>
                <th>Title</th>
                <th>status</th>
                <th>Description</th>
            </tr>
        </thead>

        <tbody>
            <c:forEach var="book" items="${books}">
                <tr>
                    <td>${book.title}</td>
                    <c:set var="status" value="일반" />
                    <c:choose>
                        <c:when test="${book.status eq 'NORMAL'}">
                            <c:set var="status" value="일반" />
                        </c:when>
                        <c:when test="${book.status eq 'RENTNOW'}">
                            <c:set var="status" value="대여중" />
                        </c:when>
                        <c:otherwise>
                            <c:set var="status" value="분실중" />
                        </c:otherwise>
                    </c:choose>
                    <td>${status }</td>
                    <td>${book.comment}</td>
                </tr>
            </c:forEach>
        </tbody>
    </table>
</div>
</body>
</html>


2. JSTL fmt를 이용한 데이터의 가공

java의 원 데이터를 html로 표시할 때, 우리는 자주 데이터의 모양을 바꿔야지 되는 일들이 발생됩니다. 특히 통화량과 날짜, 소숫점의 표시에서 가장 일반적이라고 할 수 있습니다. 자리수 단락에서 ","를 추가한다던지, 소숫점 이하의 자리수를 어떻게 표시를 하는지에 대한 문제는 Controller와 같은 기술적인 issue와는 별개로 사용자들에게는 '모든 것'이 될 수 있는 문제입니다. 이런 일은 수치데이터를 직접 바꾸는 것이 아니라 수치의 표시를 어떻게 해줄 것인지에 대한 내용입니다. View에서 이런 일들을 해주는 것이 가장 좋습니다. 

이 부분에 대해서는 issue가 있습니다. View에서 특정 데이터를 빨간색으로 보여야지 되는 action에 대한 처리를 무엇으로 보느냐에 대한 논쟁입니다. 이것은 보는 방법을 바꾸는 일이기 때문에 View에서 봐야지 된다는 의견과 보는 방법이 아닌 이것 역시 Business Logic으로 보는 견해도 있습니다. BL이기 때문에 Server Code에서 구동이 되고 테스트가 가능한 방법으로 만들어야지 된다는 것이지요. 가장 좋은 위치는 Controller 영역으로 이야기하고 있습니다. 보여지는 Model을 변경하는 것이기 때문에 가장 좋은 Layer이니까요. 개인적인 의견으로는 View에 대한 영역은 모두 View에 넘기는 것이 좋지 않나. 라는 생각입니다. 저는 개인적으로는 전자의 의견에 좀더 한표를 주고 있는 편입니다. 이 부분에 대해서는 개발자들의 취향과 그 프로젝트의 PM에 따라서 많이 바뀌게 될 내용이라고 생각됩니다. 

지금 소개하는 JSTL fmt의 경우에는 View Layer, 즉 JSP에서 보이는 방법을 바꿔주는 방법입니다. 

선언 방법은 다음과 같습니다. 

<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt"%>

선언된 데이터는 다음과 같이 사용이 가능합니다. 

<div class="example-form">
    <fieldset>
        <legend>FMT examples - Date</legend>
        <ul>
            <li><fmt:formatDate value="${date}" type="DATE" pattern="yyyy/MM/dd" /></li>
            <li><fmt:formatDate value="${date}" type="DATE" pattern="yyyy년 M월 dd일" /></li>
        </ul>
    </fieldset>
    <br />
    <fieldset>
        <legend>FMT example - Number</legend>
        <ul>
            <li>orginal : ${number}</li>
            <li><fmt:formatNumber value="${number}" groupingUsed="true" currencySymbol=","/></li>
            <li><fmt:formatNumber value="${number}" minFractionDigits="5"/></li>
            <li><fmt:formatNumber value="${number}" type="CURRENCY"/></li>
            <li><fmt:formatNumber value="234.3" pattern="△#,##0.00; ▼#,##0.00" /></li>
            <li><fmt:formatNumber value="-1234.56" pattern="△#,##0.00; ▼#,##0.00" /></li>
            <li><fmt:formatNumber value="0.99" type="percent"/></li>
        </ul>
    </fieldset>
</div>


위 HTML은 다음과 같이 표시가 됩니다. 



3. tiles

Tiles는 기본적으로 JSTL을 이용하지만, JSTL에서 중복되는 html code를 최소화하기 위해서 만들어진 Template Engine입니다. Tile는 기본적인 Html View 가 Composite View Pattern으로 동작할 때, 중복되는 코드들을 공통 요소로 뽑아서 이용가능합니다. 다음은 Tile에 대한 기본 개념의 정의입니다. 




일반적인 Html Page의 기본 구조입니다. 이 구조에서 페이지가 바뀌게 된다면 Body부분의 Content는 계속해서 바뀌게 되지만, Menu, Header, Footer들은 크게 바뀌지 않는 것이 일반적입니다. 
따라서, 각 부분을 재사용할 수 있다면 코드의 양은 매우 줄어들고, 유지보수에 용의함을 알 수 있습니다. 


tiles를 추가하기 위해서는 pom.xml에 다음 항목을 추가해주세요. 

        <dependency>
            <groupId>org.apache.tiles</groupId>
            <artifactId>tiles-jsp</artifactId>
            <version>3.0.1</version>
        </dependency>

tiles는 tag를 제공하고 있으며, tag를 이용해서 tiles page를 작성할 수 있습니다.  먼저 layout page를 알아보도록 하겠습니다. 

<%@ taglib prefix="tiles" uri="http://tiles.apache.org/tags-tiles"%>
<%@ 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><tiles:insertAttribute name="title"/></title>
<link href="/res/css/bootstrap.min.css" rel="stylesheet" />
<link href="/res/css/sample.css" rel="stylesheet" />
<script src="/res/js/bootstrap.min.js"></script>
</head>
<body>
    <tiles:insertAttribute name="content"/>
</body>
</html>

기본적인 content의 attribute를 지정하고, 그 attribute에 원하는 값을 넣어주는 것이 가능합니다. attribute는 String 문자열 또는 jsp 파일이 될 수 있습니다.  이러한 attribute와 view name을 설정하기 위해서 tiles는 설정 xml을 가지게 되는데, 이 xml은 다음과 같이 구성될 수 있습니다. 

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE tiles-definitions PUBLIC
       "-//Apache Software Foundation//DTD Tiles Configuration 3.0//EN"
       "http://tiles.apache.org/dtds/tiles-config_3_0.dtd">
<tiles-definitions>
    <definition name="main-layout" template="/WEB-INF/tiles/layouts/main-layout.jsp">
        <put-attribute name="title" value=""/>
        <put-attribute name="content" value=""/>
    </definition>
    <definition name="book/list" extends="main-layout">
        <put-attribute name="title" value="BOOK LIST"/>
        <put-attribute name="content" value="/WEB-INF/tiles/book/list.jsp"/>
    </definition>   
    <definition name="book/add" extends="main-layout">
        <put-attribute name="title" value="Add BOOK"/>
        <put-attribute name="content" value="/WEB-INF/tiles/book/add.jsp"/>
    </definition> 
</tiles-definitions>

여기서 각각의 definition name은 ModelAndView의 view name으로 이용됩니다. extends로 선언된 View를 Template로 이용하고, 각각의 View의 조각(tile)을 붙이는 형식으로 사용할 수 있습니다. 
tiles를 사용하기 위해서는 TilesViewResolver를 applicationContext에 선언해줘야지 됩니다. 일반적으로 controller-servlet.xml에서 구성합니다.  code base configuration은 다음과 같이 설정해줍니다. 

    @Bean
    public TilesConfigurer tilesConfigurer() {
        TilesConfigurer tilesConfigurer = new TilesConfigurer();
        tilesConfigurer.setDefinitions(new String[] { "/WEB-INF/tiles-configs.xml" });
        return tilesConfigurer;
    }

    @Bean
    public TilesViewResolver tilesViewResolver() {
        TilesViewResolver tilesViewResolver = new TilesViewResolver();
        tilesViewResolver.setOrder(1);
        return tilesViewResolver;
    }

2개의 @Bean을 설정해주는 것을 알 수 있습니다. 

보시면 <tiles:insertAttribute> tag로 구성된 부분에 tiles.xml 파일에서 지정한 tile이 들어가서 전체 웹페이지를 구성하게 되는 것을 알 수 있습니다. 매우 자주 쓰이고 있는 View Teamplate입니다. 전체 코드의 양을 줄일 수 있고, 전체 Framework 등의 문제를 쉽게 해결할 수 있는 방법이기도 합니다. 

tiles를 사용하시면 이제 book/list.jsp는 다음과 같이 변경이 될 수 있습니다.

<h2>jstl test code 입니다.</h2><div class="example-form">
    <h3>c:forEach example code</h3>
    <spring:message code="code.message"></spring:message>
    <table class="table table-striped table-bordered table-hover">
        <thead>
            <tr>
                <th>Title</th>
                <th>status</th>
                <th>Description</th>
            </tr>
        </thead>

        <tbody>
            <c:forEach var="book" items="${books}">
                <tr>
                    <td>${book.title}</td>
                    <c:set var="status" value="일반" />
                    <c:choose>
                        <c:when test="${book.status eq 'NORMAL'}">
                            <c:set var="status" value="일반" />
                        </c:when>
                        <c:when test="${book.status eq 'RENTNOW'}">
                            <c:set var="status" value="대여중" />
                        </c:when>
                        <c:otherwise>
                            <c:set var="status" value="분실중" />
                        </c:otherwise>
                    </c:choose>
                    <td>${status }</td>
                    <td>${book.comment}</td>
                </tr>
            </c:forEach>
        </tbody>
    </table></div>

layout에서 body 부분만을 제외하고 나머지 부분들을 모두 처리하고 있기 때문에 중복 코드를 없앨수 있는 것을 볼 수 있습니다. 조금 더 응용할 경우, 보다더 복잡한 UI를 좀 더 깔끔한 코드로 만들어주는 것이 가능합니다. Tiles의 경우에는 현장에서 주로 사용하고 있는 View Template 입니다. 꼭 사용법을 익혀주시길 바랍니다. 

4. velocity

Velocity는 JSTL의 문법의 복잡함을 해결하기 위해서 구성된 View Template 입니다. 기본적으로 제어문의 간편함과 간결한 html을 가능하게 하는 장점을 가지고 있습니다. 
기본적인 velocity로 구성된 html 파일을 한번 알아보도록 하겠습니다. (* velocity로 구성된 html파일은 대체적으로 .vm 확장자를 갖습니다.) velocity를 주로 이용하는 경우에는 eclipse에 velocity plugin을 설치하는 것이 좋습니다. Install New Software를 선택해서 http://veloeclipse.googlecode.com/svn/trunk/update/ 주소에서 veloctiy plugin을 설치해주면 .vm 파일의 syntax highlight가 가능합니다. 

기본적인 velocity 문법은 #으로 시작되는 제어문과 $로 시작되는 변수로 함축할 수 있습니다.  만들어진 book list에 대한 velocity code는 다음과 같습니다. 

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Velocity View Example</title><link href="/res/css/bootstrap.min.css" rel="stylesheet" /><link href="/res/css/sample.css" rel="stylesheet" /><script src="/res/js/bootstrap.min.js"></script></head><body>
    <h2>freemarker list view</h2>
    <div class="example-form">
        <h3>Book list</h3>
        <spring:message code="code.message"></spring:message>
        <table class="table table-striped table-bordered table-hover">
            <thead>
                <tr>
                    <th>Title</th>
                    <th>status</th>
                    <th>Description</th>
                </tr>
            </thead>
            <tbody>
                #foreach($book in $books)
                <tr>
                    <td>$book.title</td>
                    #if($book.status == "NORMAL")
                        <td>일반</td>
                    #elseif($book.status == "RENTNOW")
                        <td>대여중</td>
                    #else
                        <td>분실</td>
                    #end
                    <td>$book.comment</td>
                </tr>                
                #end
            </tbody>
        </table>
    </div></body></html>

주의해서 보실 것이 #foreach와 #if문입니다.  jstl보다는 문법이 매우 쉬워지는 것을 알 수 있습니다. 좀더 보기도 편한것도 사실이고요. 

ViewResolver를 등록하기 위해서 Spring은 2개의 Bean을 정의하도록 되어 있습니다. 위에 Tiles에서와 완전히 동일합니다. 먼저 ViewConfigurer를 등록하고, ViewResolver를 등록하는 형식입니다. ViewConfigurer의 경우에는 View에 대한 Configuration을 주로 등록을 하고, ViewResolver의 경우에는 Resolver의 세부 설정을 넣는 형식입니다. Velocity의 code base configuration은 다음과 같이 구성됩니다. 

    @Bean
    public VelocityConfigurer velocityConfigurer() throws VelocityException, IOException {
        VelocityConfigurer configurer = new VelocityConfigurer();
        configurer.setResourceLoaderPath("/WEB-INF/vm");
        Properties properties = new Properties();
        properties.put("input.encoding", "UTF-8");
        properties.put("output.encoding", "UTF-8");
        configurer.setVelocityProperties(properties);

        return configurer;
    }

    @Bean
    public VelocityViewResolver velocityViewResolver() {
        VelocityViewResolver viewResolver = new VelocityViewResolver();
        viewResolver.setContentType("text/html; charset=UTF-8");
        viewResolver.setSuffix(".vm");
        viewResolver.setOrder(3);
        return viewResolver;
    }

Configurer에서 encoding을 설정하는 것을 잊지 말아주세요. 한글 데이터가 있는한, 그리고 영문만을 사용하지 않는한 모든 ViewResolver는 어떻게든 UTF-8 설정이 필요합니다. 


5. Freemarker

Freemarker는 기본적으로 velocity와 동일한 컨셉의 View Template Engine입니다. Velocity보다 빠르고, 가독성의 향상을 목적으로 하고 있습니다. 다음은 Freemarker로 만든 Html code입니다. 

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title><tiles:insertAttribute name="title"/></title><link href="/res/css/bootstrap.min.css" rel="stylesheet" /><link href="/res/css/sample.css" rel="stylesheet" /><script src="/res/js/bootstrap.min.js"></script></head><body>
    <h2>freemarker list view</h2>
    <div class="example-form">
        <h3>Book list</h3>
        <spring:message code="code.message"></spring:message>
        <table class="table table-striped table-bordered table-hover">
            <thead>
                <tr>
                    <th>Title</th>
                    <th>status</th>
                    <th>Description</th>
                </tr>
            </thead>

            <tbody>
                <#list books as book>
                    <tr>
                    <td>${book.title}</td>                    
                    <#if book.status.name() == "NORMAL">
                        <td>일반</td>
                    <#elseif book.status.name() == "RENTNOW">
                        <td>대여중</td>
                    <#else>
                        <td>분실</td>
                    </#if>
                    <td>${book.comment}</td>
                    </tr>
                </#list>
            </tbody>
        </table>
    </div></body></html>

#을 이용한 간편한 foreach문이 보이시나요? #if 등 문법상으로는 개인적으로는 좀더 편해보이는 것이 freemarker이긴합니다. freemarker를 사용하기 위해서는 velocity와 동일하게 ViewConfiguration과 ViewResolver를 구성해야지 됩니다. 다음은 code base configuration입니다. 

    @Bean
    public FreeMarkerConfigurer freemarkerConfigurer() {
        FreeMarkerConfigurer freemarkerConfigurer = new FreeMarkerConfigurer();
        freemarkerConfigurer.setTemplateLoaderPath("/WEB-INF/fmt");
        Properties properties = new Properties();
        properties.put("default_encoding", "UTF-8");
        freemarkerConfigurer.setFreemarkerSettings(properties);
        return freemarkerConfigurer;
    }

    @Bean
    public FreeMarkerViewResolver freemarkerViewResolver() {
        FreeMarkerViewResolver viewResolver = new FreeMarkerViewResolver();
        viewResolver.setContentType("text/html; charset=UTF-8");
        viewResolver.setSuffix(".ftl");
        viewResolver.setOrder(2);

        return viewResolver;
    }


Summary

지금까지 다양한 Html View Engine을 살펴봤습니다. View Engine은 매우 다양한 형태로 제공되고 있습니다. 지금 소개한 Veloctiy, Freemarker, tiles의 경우에는 Spring에서 공식적으로 제공하고 있는 View Template Engine입니다. 타 View Template Engine의 경우, Library에 Spring의 ViewResolver를 구현하고 있는 것이 일반적입니다. 다양한 View Engine은 Project에서 개발자의 맘 또는 전체 개발팀의 의향으로 정해지는 것이 일반적입니다. 그런데, 여기에서 조금 문제가 되는 것이 여러개의 View Engine을 섞어서 쓰지는 거의 못한다는 겁니다. 물론 섞어서 사용하는 경우도 왕왕 있습니다. 예를 들어, tiles에 freemarker를 섞어서 사용한다던지요. 이 부분에 대해서는 각자 개인의 학습이 좀 더 필요한 것 같습니다. 저도 몇 부분은 좀 더 해봐야지 될 것 같고요. 

가장 대중적인 것은 jstl을 사용하는 것입니다. 모든 View Template의 기본이 되고 있고, 많은 Reference를 가지고 있습니다. Tiles + JSTL의 경우가 호환성이나 code의 편의성이 가장 좋은 것 같습니다. 

숙제입니다. BookList를 jsp, tiles, velocity, freemarker를 이용해서 표시해주세요. 4개의 html page와 4개의 Template engine의 설정이 필요합니다. 반드시 한글 데이터가 나오도록 설정되어야지 됩니다. 또한 각 ViewEngine이 한 web server에서 동작하도록 구성을 해주시길 바랍니다.


Posted by Y2K
,

22. Spring View 처리 구조

Java 2013. 9. 12. 13:41

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


View는 사용자에게 최종적으로 보이는 영역입니다. 이 영역은 우리가 일반적으로 보는 Html이 될 수도 있고, Mobile App에게는 JSON format의 API 결과가 될 수도 있습니다. 
기본적으로 Spring Servlet/MVC를 기반으로 동작하게 됩니다. View 계층 또는 Presentation 계층이라고 합니다. 

Controller가 return한 결과에 대한 표현을 담당하는 영역으로 Controller가 넘겨주는 ModelAndView가 View에서 핵심 객체라고 할 수 있습니다. 

기본적인 동작은 DispatcherServlet이 ModelAndView에서 넘어온 값 ViewResolver를 통해서 해석한 결과를 사용자에게 보내줍니다. ViewResolver는 기본적으로 jsp를 기반으로 하고 있고, jsp 이외에 모든 web context가 될 수 있습니다. 

View의 기본 구조

기본적으로 Spring의 org.springframework.web.servlet.View interface를 구현한 객체를 View로 표현이 가능합니다. 일반적으로 View는 Spring 내부의 View를 확장하거나, pdf, rss, excel과 같은 다른 형태의 View를 표현하기 위해서 class를 확장해서 사용합니다. 또는 외부 View engine을 이용한 View의 표현 역시 가능합니다. 여기서 외부 View engine을 이용하는 것은 velocity, freemarker, tiles와 같은 외부의 View engine과의 연결 interface 및 설정을 구현함으로서 가능합니다. 

View의 기본 동작

Controller가 작업을 마친 후, View정보를 ModelAndView 객체에 담아서 보내주는 DispatcherServlet에 보내주는 것이 기본 동작입니다. 이에 대한 방법은 Spring @MVC는 두가지를 제공하고 있습니다. 첫번째는 View interface를 구현한 객체를 보내주는 방법이고, 다른 하나는 View의 이름만을 보내는 방법입니다. 첫번째 방법의 경우에는 View interface의 구현 방법에 따라 다양한 View를 표시하게 됩니다. DispatcherServlet과 Controller간에는 어떠한 동작도 존재하지 않습니다. 그렇지만 View의 이름만 보내주는 방식은 좀 다르게 동작하게 됩니다. 

View의 이름으로 표현되는 논리적인 View를 실질적인 View interface를 구현한 객체로 변경하는 작업이 필요하게되는데요. 이를 담당하는 객체를 ViewResolver라고 합니다. 
Spring에서 제공하는 주요 ViewResolver는 다음과 같습니다. 

ViewResolver 구현 classDescription
InternalResourceViewResolverView Name에서 jsp나 tiles 연동을 위한 View 객체를 반환
BeanNameViewResolverBean name을 기준으로 View 객체를 반환
ResourceBundlleViewResolverView 이름과 View 객체간의 mapping 정보를 저장하기 위해서 Resource 파일을 이용
XmlViewResolverView 이름과 View 객체간의 mapping 정보를 저장하기 위해서 xml 파일을 이용


기본적으로 만들어지는 ViewResolver의 interface는 다음과 같습니다. 
public interface ViewResolver {
    View resolveViewName(String viewName, Locale locale) throws Exception;
}

다국어 지원을 위한 locale 정보와 View 이름을 이용한 View 객체를 얻어내는 간단한 interface만을 가지고 있습니다. 이를 이용해서 새로운 ViewResolver를 만드는 것 역시 가능합니다. 

구성되는 View는 다음과 같은 interface를 가지고 있습니다. 

public interface View {
    String RESPONSE_STATUS_ATTRIBUTE = View.class.getName() + ".responseStatus";
    String PATH_VARIABLES = View.class.getName() + ".pathVariables";
    String SELECTED_CONTENT_TYPE = View.class.getName() + ".selectedContentType";
    String getContentType();
    void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception;
}

들어오게되는 model을 어떻게 render하는지에 대한 interface 선언을 볼 수 있습니다. 

자, 전에 봤던 Spring MVC에서 Request가 처리되는 과정을 다시 한번 봐보도록 하겠습니다. 

지금까지는 Step2까지 알아본 상황입니다. 이제 Step 2에서  Step 3 사이의 ModelAndView가 Return이 되고 ViewResolver가 ViewName을 통해서 실질적인 View를 Return 시켜주는 영역을 알아봐야지 됩니다. 그리고, 그 설정은 Spring에서 제공하는 ViewResolver interface에서 담당하고 있습니다.  위 그림에서 Step 3이 생략되는 경우 역시 존재할 수 있습니다. 앞에서 이야기한것 처럼, 직접 View가 return 될 때에는 Step 3의 ViewResolver가 동작을 하지 않고, 바로 Step 4로 이동하게 됩니다. 



Summary

이번장에서는 Controller가 return 시켜주는 Model을 render 시켜주는 View interface에 대해서 알아봤습니다.  Spring MVC에서 Request가 처리되는 과정을 좀 더 살펴보시길 바랍니다. 


Posted by Y2K
,

21. Controller - Spring 3.x

Java 2013. 9. 12. 13:39

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



기존 Spring 2.x 대의 Controller의 문제점을 해결하기 위한 수단으로 새로운 Controller Mapping 방법이 나오게 되었습니다. 이 방법은 지금 Spring Controller 부분의 표준으로 사용되고 있으며, 기존 코드를 완벽하게 대치하고 있습니다. 

기존 Spring 2.x 대의 Controller의 문제점은 다음과 같습니다.

1. 특정 interface를 반드시 상속받는 형태여야지 된다.
2. bean name을 이용한 method - url mapping이 된다.
3. POST/GET/DELTE/PUT/HEAD 와 같은 http method에 적합하지 않다.
4. url 당 1개의 Controller 객체가 생성되기 때문에 Enterprise 개발에 적합하지 않다.

기존에 Controller Interface를 구현해야지 되었으나, 3.0대의 @MVC는 annotation을 이용해서 @Controller로 객체의 meta 정보를 적는 것으로 해결이 가능합니다. 

다음과 같은 코드로 기존과 동일한 Controller가 구현 가능합니다. 

@Controller
public class HelloController {
    @Autowired
    private HelloString helloString;
    
    @RequestMapping(value="index", method=RequestMethod.GET)
    public String index(@RequestParam(value="name") String name, ModelMap model) {
        model.addAttribute("message", helloString.say(name));
        return "hello";
    }
}


기본적으로 @Controller를 이용, component-scan으로 bean으로 등록시켜서 사용 가능합니다. mapping 시킵니다. 그리고, 각 method에 Mapping url을 각각 지정해주는 방식으로 처리가 가능합니다. 여기서 return값에 주목할 점이 있습니다. 기존에는 return값으로 ViewAndModel을 보내줘야지 되었지만, 이제는 input값으로 Response에 보내질 model을 미리 준비해서 받는것 역시 가능합니다. 이 코드는 method의 in/out의 type을 강제하지 않고, 특정한 객체에 대한 상속을 피하고, URL에 대한 mapping을 한개의 class에서 처리 가능한, Spring의 특징 및 장점을 모두 갖는 코드라고 할 수 있습니다. 

URL mapping의 기본이 되는 RequestMapping 에 대해서 좀 더 알아보도록 하겠습니다.


@RequestMapping

String[] value
URL을 지정해주는 pattern입니다. 예를 들어 다음과 같은 pattern들을 지정해주는 것이 가능합니다.
1. @RequestMapping("/hello")
2. @RequestMapping({"/hello", "/hello2"})
3. @RequestMapping("/hello1")

Path변수를 지정해주는 것이 가능합니다. "/hello/{name}" 과 같이 method의 input을 url에 같이 실어 주는것이 가능합니다.
1. @RequestMapping("/hello/{name}")
2. @RequestMapping("/hello/{name}/{number}")

method
RequestMethod를 지정하는 것 역시 가능합니다. GET, POST, DELETE, PUT, HEAD가 사용 가능합니다. 역시 method도 Path와 동일하게 중복 설정이 가능합니다.

params
url 요청 파라미터의 유무에 따라 호출되는 method를 결정할 수 있습니다.
1. RequestMapping(value="/user/edit", params="type=admin")
2. RequestMapping(value="/user/edit", params="type=member")

이 두 url은 다음 실제 Url과 mapping 됩니다.
* /user/edit?type=admin
* /user/edit?type=member

method의 input값에 따라 method내에서의 if문을 만들지 않고 처리가 가능한 유용한 팁입니다.

headers
HTTP header정보에 따른 mapping역시 가능합니다. request type을 text/html, application/json 각각의 type에 따라 다른 method를 처리 가능합니다. 

RequestMapping과 method parameter와 결합

기본적으로 @Controller의 각 method는 다음과 같은 input parameter를 갖을 수 있습니다.

TypeAnnotationDescription
URL/POST parameter@RequestParamGET/POST/DELETE/PUT 등으로 호출될 때, 넘겨지는 Parameter값
Path value@PathVariableURL 에 포함된 특정 영역 문자열
Servlet-HttpServletRequest, HttpServletResponse를 직접 Handling 하는 기존 Servlet과 같은 코드 역시 사용 가능합니다.
Cookie@CookieValueCookie 값을 얻거나 설정할 수 있습니다.
Session@SessionAttributesSession 값을 얻거나 설정할 수 있습니다.
Body@RequestBodyRequest의 Body 부분을 모두 String으로 얻어내는 것이 가능합니다.

또한 Controller의 action method는 주로 4가지 형태의 Return Type을 사용하게 됩니다. 

1. String : view 이름을 return 합니다. 주로 JSP 또는 Veloctiy, Freemarker, tiles와 Html View를 호출 할 때 사용됩니다. String 형태를 보내줄 때는 일반적으로 ViewResolver라는 객체를 applicationContext.xml에 등록하는 것이 일반적입니다.
2. void : 아무것도 return 하지 않습니다. 이는 method의 이름을 String 형태로 return 하는 것과 동일한 결과를 갖습니다.
3. Object : REST 형태의 Return값을 사용할 때 이용됩니다. 대체적으로 Object에 대한 Body Response를 덩어내는 것을 주 목적으로 하고 있습니다.
4. ModelAndView : Spring 2.X 형태로 Model과 View를 return 하는 것이 가능합니다. 

여기서 ModelAndView 형태의 return값은 pdf, excel 과 같은 데이터를 다운받는 형태로 사용 가능합니다. 이 부분은 뒤에 View에서 다시 다루도록 하겠습니다. 


Spring 3.x를 이용한 Hello World


기본적으로 그 전에 만들었던 Spring 2.x의 Hello World와 유사한 코드가 만들어집니다. Spring 2.x대의 코드와 동일한 설정을 해서 project를 하나 만들도록 하겠습니다. 아니면 기존의 project를 다른 이름으로 copy 해서 import 해도 괜찮습니다.
간단하게 HelloController를 작성해보도록 하겠습니다. @Controller를 이용한 처리를 하더라도 Controller의 경우에는 Controller라는 이름을 붙여주는 것이 일반적입니다. 

@Controller
public class HelloController {
    @Autowired
    private HelloString helloString;
    @RequestMapping(value="/index", method=RequestMethod.GET)
    public String index(@RequestParam(value="name") String name, ModelMap model) {
        model.addAttribute("message", helloString.say(name));
        return "hello";
    }
}

아주 간단한 코드입니다. 기존과 다르게 String 형태로 return을 시켰습니다. 지금 코드 그대로면 webapp/hello 파일을 찾게 되고, 이건 에러가 발생하게 됩니다. 따라서 기본적으로 사용할 ViewResolver를 등록시켜줘야지 됩니다. 


  <bean
    class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/jsp/" />
    <property name="suffix" value=".jsp" />
    <property name="order" value="1" />
  </bean>

지금까지 등록된 bean과는 조금 다른 형태입니다. 지금까지는 id값을 가지고 있었지만, id나 name이 없는 bean 등록입니다. spring을 사용한 개발을 하다보면 이렇게 등록되는 경우가 왕왕 있습니다. 주로 Spring 내부에서 사용할 bean 또는 모든 applicationContext에서 하나만 존재할 bean 들의 경우 id/name을 갖지 않아도 됩니다. 
그리고, @Controller를 url에 mapping 해주는 과정을 해줘야지 됩니다. 이는 context:component-scan 을 이용해서 해주면 되고, applicationContext에는 다음과 같이 위치시키면 됩니다. 

  <context:component-scan base-package="com.xyzlast.mvc.spring02.controllers" />

프로젝트의 구조를 잘 파악할 수 있어야지 됩니다. 지금 구성된 전체 Project의 구조는 다음과 같습니다.


web.xml을 구성해야지 됩니다. web.xml을 구성할 때, 앞으로 개발하기 좀 더 편하게 다음과 같은 설정을 추가하도록 하겠습니다. 모든 request에 .do가 붙는 경우에는 모두 spring에서 처리하도록 web.xml을 수정하도록 하겠습니다. 수정된 web.xml은 다음과 같이 구성됩니다. servlet-mapping에서 url-pattern이 구성된 방법을 확인해주세요. 이 pattern을 넣는것은 매우 중요한 의미를 갖습니다. .do가 아닌 .html과 잘 알려진 확장자 역시 처리가 가능합니다. 이러한 설정을 이용해서, spring을 통해서 작성된 web인지, 아니면 그냥 html인지 외부에서 착각을 유도하는 것도 가능합니다. 정부표준 프레임워크 등 대부분의 Framework에서는 .do를 사용하고 있습니다. 그리고 nhn에서는 .nhn을 붙여서 사용하고 있습니다. 다른 일반적인 file path들과 중복되지 않는 이름을 사용하는 것이 중요합니다. 


<?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"
  version="3.0">
  <display-name>mvc.spring02</display-name>
  <welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>
  <listener>
    <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>*.do</url-pattern>
  </servlet-mapping>
</web-app>

그리고, applicationContext.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" xmlns:mvc="http://www.springframework.org/schema/mvc"
  xsi:schemaLocation="http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.2.xsd
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
  <bean id="helloString" class="com.xyzlast.mvc.spring02.entities.HelloString"></bean>
</beans>

마지막으로 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"
  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">
  <context:component-scan base-package="com.xyzlast.mvc.spring02.controllers" />
  <bean
    class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/jsp/" />
    <property name="suffix" value=".jsp" />
    <property name="order" value="1" />
  </bean></beans>

구성후 테스트 코드를 작성해보도록 하겠습니다. 테스트 코드 소스는 다음과 같습니다. 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"file:src/main/webapp/WEB-INF/applicationContext.xml", "file:src/main/webapp/WEB-INF/controller-servlet.xml"})
@WebAppConfiguration
public class HelloControllerTest {
    @Autowired
    private WebApplicationContext context;
    private MockMvc mvc;

    @Before
    public void setUp() {
        mvc = webAppContextSetup(context).build();
        assertThat(mvc, is(not(nullValue())));
    }

    @Test
    public void index() throws Exception {
        MvcResult result = mvc.perform(get("/index").param("name", "ykyoon")).andExpect(status().isOk()).andReturn();
        Object model = result.getModelAndView().getModel().get("message");
        assertThat(model, is(not(nullValue())));
        String message = (String) model;
        assertThat(message.endsWith("ykyoon"), is(true));
    }
}

마지막으로 jetty를 추가 후, maven jetty:run을 이용해서 프로젝트를 구동해보시길 바랍니다.
구성된 project의 pom.xml은 다음과 같습니다.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.xyzlast</groupId>
  <artifactId>mvc.spring02</artifactId>
  <packaging>war</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <name>mvc.spring02 Maven Webapp</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <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>
  </dependencies>
  <build>
    <finalName>mvc.spring02</finalName>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.0</version>
        <configuration>
          <source>1.7</source>
          <target>1.7</target>
        </configuration>
      </plugin>
      <plugin>
      <plugin>
       <plugin>
            <groupId> org.eclipse.jetty</groupId>
            <artifactId>jetty-maven-plugin</artifactId>
        </plugin>
      </plugin>
    </plugins>
  </build>
</project>


확장자가 없는 URL

지금까지의 예시에서는 확장자를 하나씩 붙여서 처리했습니다. 이러한 확장자를 붙여서 처리하는 것은 DispatcherServlet에서 처리할 URL이 어떤 것인지 명확하게 결정해줄 수 있는 장점을 가지고 있습니다. 그렇지만, 이 방법은 조금 애매한 것이 사실입니다. W3C에서 표준한 URL 표준에서, 확장자는 URL을 통해서 얻고 싶은 Response의 protocol을 선택하는 형식입니다. 예를 들어서 다음 URL들의 해석은 다음과 같습니다. 

/shop/search.json?name=윤영권
/shop/search.html?name=윤영권
/shop/search.rss?name=윤영권
/shop/search.xml?name=윤영권

다음 4개의 url format은 json/html/rss/xml 형식으로 데이터를 얻어오는 것을 가정하고 있습니다. url의 extension에 dispatcher servlet 을 종속시키는 것은 이제 옛날 방법입니다. 이제는 모든 URL을 dispatcherServlet에 보내게 됩니다. 그리고 dispatcherServlet에서 해석 불가능한 request들은 servlet container에게 넘기는 방식으로 처리하는 것입니다. 

여기서 servlet spec에 대해서 한번 알아보도록 하겠습니다. SRV.11.2 Specification of Mappings 에서 servlet container는 다음과 같이 명령을 정의하고 있습니다. 

In theWeb application deployment descriptor, the following syntax is used to define mappings:
1. A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
: '/'로 시작하고, '/*'로 끝나는 mapping의 경우에는 path mapping을 따르게 된다.
(path mapping : servlet container에서 정의되어 있는 mapping입니다.)
2. A string beginning with a ‘*.’ prefix is used as an extension mapping.
: *. 으로 시작하는 mapping의 경우에는 확장 mapping을 따르게 된다. 우리가 기존에 사용하는 것을 확인했던 *.do와 같은 방법입니다.
3. A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
: '/'만 사용하게 되는 경우, 이는 application의 'default' servlet을 의미한다. 이 경우에는 request URI와 context Path가 완전히 일치하게 되고, servlet path는 null이 됩니다.
4. All other strings are used for exact matches only.
: 모든 request uri가 완전히 일치하는 경우

이 4가지 경우중에서 우리가 사용하게 되는 것은 3번으로 mapping을 설정하게 됩니다. 이는 결국에 원 servlet container의 default servlet의 목적을 바꿔버리는 결과를 가지고 옵니다. 이렇게 설정하는 경우, web.xml은 다음과 같이 설정할 수 있습니다. 

    <servlet-mapping>
        <servlet-name>controller</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

그리고 이렇게 설정하는 경우에 반드시 servlet-configuration에 다음과 같은 설정을 추가해줘야지 됩니다. 
<mvc:default-servlet-handler/>

앞으로 모든 url은 위와 같은 format으로 설정하게 될 것입니다. 

@Configuration을 이용한 DispatcherServlet 설정

Controller들을 선언하는 DispatcherServlet의 설정의 경우에는 DispatcherServletName + "-servlet.xml"의 형식으로 기본적으로 구성되게 됩니다. 이 설정을 @Configuration을 이용해서 변경해보도록 하겠습니다. 
먼저, 지금까지 구성된 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"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:mvc="http://www.springframework.org/schema/mvc"
    xsi:schemaLocation="http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.2.xsd
        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">
  <context:component-scan base-package="com.xyzlast.mvc.spring02.controllers" />
  <bean
    class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/jsp/" />
    <property name="suffix" value=".jsp" />
    <property name="order" value="1" />
  </bean>
  <mvc:default-servlet-handler />
</beans>

ViewResolver를 등록하고, default-servlet-handler를 등록하는 것 이외에는 설정이 거의 없습니다. spring-servlet.xml을 대치하는 @Configuration을 구성의 편의성을 높이기 위해서 Spring은 abstract class를 제공하고 있습니다. 이 코드를 시용하면 보다 더 쉽게 처리가 가능합니다. xml을 이용해서 설정하는 것보다 나중에는 훨씬 편한 설정을 제공하기 때문에, 이는 꼭 @Configuration을 이용해서 구성하기실 바랍니다. 훨씬 편합니다. 

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = { "com.xyzlast.mvc.spring02.controllers" })
public class ControllerConfiguration extends WebMvcConfigurerAdapter {
    @Override
    public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
        configurer.enable();
    }

    @Bean
    public InternalResourceViewResolver internalResourceViewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setViewClass(JstlView.class);
        viewResolver.setPrefix("/WEB-INF/jsp/");
        viewResolver.setSuffix(".jsp");
        viewResolver.setOrder(1);
        return viewResolver;
    }
}

WebMvcConfigurerAdapter를 이용하는 경우, DefaultServletHandlerConfigurer 등 여러 항목들을 편하게 설정이 가능합니다. override가 가능한 method들이 주목할 만한 것들이 많습니다. 나중에 나올 initBinder, formatter 등의 설정 역시 위 class에서 가능하기 때문에 여간해서는 xml을 사용하지 않기를 바랍니다. 

마지막으로 web.xml을 구성하는 방법에 대해서 간단히 소개를 드린 내용을 정리해보도록 하겠습니다. 

@Configuration  + web.xml을 이용한 설정

@Configuration class를 이용한 설정을 web.xml에 반영하기 위해서는 web.xml의 기본 ContextLoader의 설정을 변경해야지 됩니다.  기본적으로 web.xml의 ContextLoaderListener는 XmlConfigWebApplicationContext를 설정하고 있습니다. 이를 AnnotationConfgWebApplicationContext로 변경해야지 됩니다. 그리고 child applicationContext 역시, DispatcherServlet의 contextClass를 XmlConfigWebApplicationContext로 변경하고 @Configuration class로 변경하는 것이 필요합니다. 변경되는 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"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <context-param>
        <param-name>contextClass</param-name>
        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </context-param>
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>com.xyzlast.bookstore.domain.config.DomainConfiguration</param-value>
    </context-param>
    <servlet>
        <servlet-name>controller</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextClass</param-name>
            <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
        </init-param>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>com.xyzlast.bookstore.web.configs.WebMvcContexConfiguration</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>controller</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

    <filter>
        <filter-name>characterEncodingFilter</filter-name>
        <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
        <init-param>
            <param-name>encoding</param-name>
            <param-value>utf-8</param-value>
        </init-param>
        <init-param>
            <param-name>forceEncoding</param-name>
            <param-value>true</param-value>
        </init-param>
    </filter>
    
    <filter-mapping>
        <filter-name>characterEncodingFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

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

</web-app>

객체를 넣어줄때는 package명까지 명확히 넣어줘야지 된다는 것을 잊지 말아주세요.

지금보시면 web.xml에 새로운 내용이 하나 더 추가가 되어서 보입니다. filter-mapping이 바로 그것인데요. 지금 사용한 Filter는 기본적으로 tomcat과 같은 web container는  ISO-8859-1 문자 포멧을 사용하게 됩니다. 이 포멧을 UTF-8로 사용하기 위한 기본 설정입니다. 우리나라에서는 꼭 해줘야지 되는 기본 설정입니다.


@Configuration + no web.xml을 이용한 설정 방법

web.xml이 아애 없이 개발하기 위해서는 web.xml을 대신할 객체를 만들어줘야지 됩니다. 
web.xml이 없는 경우, servlet container 즉 tomcat 또는 jetty는 자신이 가진 bin 중에서 spring 객체가 로드되면서 WebApplicationInitializer를 상속받은 객체가 있는지 확인하는 과정을 거치게 됩니다. 

이제 우리가 사용할 기본적인 WebApplicationInitializer 코드를 확인해보도록 하겠습니다. 
public class BookStoreWebApplicationInitializer implements WebApplicationInitializer {

    private static final String DISPATCHER_SERVLET_NAME = "dispatcher";

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

        addEncodingFilter(servletContext);
    }

    private void registerListener(ServletContext servletContext) {
        AnnotationConfigWebApplicationContext rootContext = createContext(DomainConfiguration.class);
        ContextLoaderListener contextLoaderListener = new ContextLoaderListener(rootContext);
        servletContext.addListener(contextLoaderListener);
        servletContext.addListener(new RequestContextListener());
    }

    private void registerDispatcherServlet(ServletContext servletContext) {
        AnnotationConfigWebApplicationContext dispatcherContext = createContext(WebMvcContexConfiguration.class);
        ServletRegistration.Dynamic dispatcher = servletContext.addServlet(DISPATCHER_SERVLET_NAME,
                new DispatcherServlet(dispatcherContext));
        dispatcher.setLoadOnStartup(1);
        dispatcher.addMapping("/");
    }

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

    private void addEncodingFilter(ServletContext servletContext) {
        CharacterEncodingFilter encodingFilter = new CharacterEncodingFilter();
        encodingFilter.setEncoding("UTF-8");
        encodingFilter.setForceEncoding(true);
        FilterRegistration.Dynamic encodingFilterRestriction = servletContext.addFilter("characterEncodingFilter",
                encodingFilter);
        encodingFilterRestriction.addMappingForUrlPatterns(null, false, "/*");
    }
}

하나하나 코드에 대해서 확인해보도록 하겠습니다. WebApplicationInitializer를 상속받으면 기본적으로 onStartup method가 abstract로 구현체로 나오게 됩니다. 이 method는 web container가 application을 로드할 때 시작되는 method가 됩니다. 

code의 private method는 다음과 같습니다. 

# registerListener : root applicationContext를 로드하는 private method입니다.
# registerDispatcherServlet : child applicationContext를 로드하고, front controller인 dispatcher servlet을 로드하는 구문입니다. 
# addEncodingFilter : Filter 적용 코드입니다.

이 코드랑, 그 전에 작성된 web.xml과 한번 비교를 해보시길 바랍니다. 완전히 1:1로 matching이 되어서 동작하는 것을 볼 수 있습니다. 
개인적으로는 가장 선호하는 방법입니다. 

위 코드도 길다고 느껴지시나요? 
Spring 3.2를 사용하실 경우에는 더욱더 간단한 코드를 작성하는 것이 가능합니다. 다음과 같습니다. 

public class WebXmlConfiguration extends AbstractAnnotationConfigDispatcherServletInitializer {

    @Override
    protected Class<?>[] getRootConfigClasses() {
        return new Class<?>[] { DomainConfiguration.class };
    }

    @Override
    protected Class<?>[] getServletConfigClasses() {
        return new Class<?>[] { WebApp01Configuration.class };
    }

    @Override
    protected String[] getServletMappings() {
        return new String[] { "/" };
    }

    @Override
    protected boolean isAsyncSupported() {
        return true;
    }

    @Override
    protected Filter[] getServletFilters() {
        CharacterEncodingFilter encodingFilter = new CharacterEncodingFilter();
        encodingFilter.setEncoding("UTF-8");
        encodingFilter.setForceEncoding(true);
        return new Filter[] { encodingFilter };
    }
}


@Configuration + WebApplicationInitializer + web.xml 을 이용하는 방법

이제 마지막 방법입니다.  만약에 WebApplicationInitializer를 상속받은 객체와 web.xml이 동시에 존재를 한다면 어떻게 동작을 할까요? 
정답은 web.xml이 먼저 적용되고, WebApplicationInitializer가 나중에 동작하게 됩니다. 이러한 구성을 사용하는 이유는 다음 항목들이 아직 WebApplicationInitializer에 구현되지 않았기 때문입니다. (servlet 3.0 규약에서 이 부분은 web.xml에서 빠져있습니다.) 

1. welcome-page
2. error-code

이 두가지를 구현하기 위해서는 반드시 web.xml을 사용해줘야지 됩니다.


Posted by Y2K
,

20. Controller - Spring 2.x

Java 2013. 9. 12. 10:53

* 사내 강의용으로 사용한 자료를 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 Y2K
,

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



Spring MVC의 구조

지금까지 Spring을 이용한 DB에 대한 접근법과 다루는 법에 대해서 알아보았습니다. 엄밀히 말하면 이 부분은 MVC pattern의 M에 해당되는 내용들입니다. Spring은 구조화된 MVC 구조를 제공하며, Layer 기반의 잘 정형화된 서비스 패턴을 제공합니다. Spring은 MVC를 기반으로 하는 Web Framework를 제공하고 이는 org.springframework.web 안에 제공되어 있습니다.
이제부터 사용할 package인 org.springframework.web에서는 C와 V에 대한 내용들을 다루고 있습니다.

Controller

간단하게 말해서, Controller는 URL과 상호동작하는 Class입니다.
/wpwoms/appuser/getshoplist 라는 URL이 호출되었을 때, Http Request가 연결되는 Class를 의미합니다.
기술적으로는 굉장히 어려운 영역입니다. 이는 Servlet container의 Http Request가 어떻게 해석이 되며, 이 해석된 Http Request에 따라 어떤 class의 어떤 method를 선택할 지에 대한 복잡한 연결을 계속해서 이어가야지 됩니다.
Controller는 기본적으로 다음과 같은 일을 합니다.
1. Servlet이 넘겨주는 HttpServletRequest를 처리한다.
2. Servlet으로 HttpServletResponse를 보내준다.
3. Cookie, Session 에 대한 동기화 작업을 지원한다.

View

View는 HTML 영역이라고 생각하시면 됩니다. 어찌보면 단순한 영역일수도 있지만... 이 부분이 어마어마한 노가다를 요구하는 부분입니다. ㅠ-ㅠ
View는 Controller가 보내주는 데이터를 Html로 표현하는 영역이라고 생각하면 됩니다.
MVC Model이 서로간에 하는 일을 간단히 표현하면 다음 그림과 같습니다.




Front Controller
기존 servlet application 작성시에, url에 각각의 servlet을 등록해서 사용하는 것을 알고 있습니다. 일반적인 MVC 구조의 Web Application은 Front Controller pattern이라고 해서, 가장 최 상단 Front Controller가 모든 Web의 Request를 처리합니다. 그리고, 처리된 Request에 따라 맞는 Controller를 찾아서 호출해주는 형식입니다.  Spring에서는 org.springframework.web.servlet.DispatcherServlet에서 FrontController를 담당합니다. 참고로, .NET에서는 ASP .NET MVC에서는 ControllerFactory가 이 일을 합니다.

Controller
org.springframework.web.servlet.DispatcherServlet에서 처리된 request가 전달되는 영역입니다. 여기에서 HTML의 경우, 화면에 보여줄 model을 생성 하고, 또는 REST API의 경우에는 보내질 객체를 결정하게 됩니다.

View
사용자, Client에게 전달될 내용입니다. Html이 될 수도 있고, JSON이 될 수도 있고, Excel File이 될 수도 있습니다.

model
MVC에서의 M과는 다른 개념입니다. 기존 MVC에서의 Model은 BL 또는 Persistance Layer의 각 model 또는 entity를 의미하지만, 이곳의 model은 View Model입니다. View에 표시되는 model은 Controller에서 작성이 되는 경우도 있고, Domain Model에서 넘겨온 값을 그대로 이용하는 경우도 있습니다. 기존에 Application의 데이터 흐름에서 이야기한 DTO, VO가 여기에 속하게 됩니다.


Spring MVC에서의 Request 처리 과정

Spring MVC는 Web Request를 다음과 같은 순서로 처리되게 됩니다. 



1. Request -> DispatcherServlet : Request가 처음 들어오게 됩니다.
2. DispatcherServlet -> Handler Mapping : DispatcherServlet은 Request를 분석하고 Mapping 중에서 Request와 동일한 Mapping을 찾아냅니다.
3. Handler Mapping -> DispatcherServlet : 찾아진 Handler Mapping을 DispatcherServlet에 전달해줍니다.
4. DispatcherServlet -> Controller : Handler Mapping에서 찾아진 Controller측에 Http Request를 전달해줍니다.
5. Controller -> DispatcherServlet : ModelAndView 객체를 보내줍니다. ModelAndView객체는 View의 이름과 View에 표시될 데이터를 가지고 있습니다.
6. DispatcherServlet -> View Resolver : View이름을 가지고 View를 처리하는 View Resolver에 ViewName을 전달합니다.
7. View Resolver -> DispatcherServlet : 이름에 맞는 View를 return 시켜줍니다.
8. DispatcherServlet -> View : View에 표시될 데이터를 가지고 있는 model을 보내줍니다.
9. View -> DispatcherServlet : model을 이용해서 View를 render 시키고, 그 결과를 DispatcherServlet에 보내줍니다.
10. DispatcherServlet -> Response : View로부터 받은 render된 결과를 Client에게 보내주게 됩니다.

위 그림과 순서는 머리에 익혀두고 있어야지 됩니다. Spring이 우리에게 감춰버리는 부분이기 때문에, 개발을 할때에는 자주 쓰이는 부분이 아니지만 디버그나 문제가 발생했을 때, 어떤 영역에서의 문제인지 확인할 필요가 있을 때 사용되는 지식입니다. 


Maven을 이용한 Hello World Web App

maven을 이용해서 Simple web application을 작성하는 법을 간단히 알아보도록 하겠습니다. 이 프로젝트는 전반적인 프로젝트들의 뼈대가 될 것입니다. 

Maven Project를 선택해줍니다.



maven-archetype-webapp을 선택해줍니다.


groupId와 artifact Id를 넣어주고, Project를 생성합니다.





지금 상태는 기본적으로 JRE1.5를 기반으로 한 Project가 구성이 되어있고, web application으로 eclipse에서 인식도 못하는 상태입니다. 프로젝트를 좀 손을 봐줘야지 됩니다.

pom.xml을 수정해서 JRE1.7기반으로 변경합니다.

       <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.0</version>
        <configuration>
          <source>1.7</source>
          <target>1.7</target>
        </configuration>
      </plugin>

Project에서 우클릭 > Property에 들어가서 Project Facets를 선택합니다.


Convert to faceted from... 을 클릭합니다. 

Dynamic Web Module과 JavaScript를 선택합니다.


하단에 나오는 Further configuration available 을 클릭합니다.

ContextRoot를 artifactId와 동일하게 설정하고, Context directory를 src/main/webapp 으로 수정하고, Generate web.xml deployment descriptor를 선택합니다. 



프로젝트가 다음 모습이 되는지 확인합니다.




다시 Project 우클릭 > Property에 들어가서, Deployment Assembly를 선택합니다.


Add를 눌러, Java Build Path Entities를 추가, Maven Dependencies를 추가합니다.

 


 /src/test/java를 제거합니다.
다음과 같이 Web Depolyment Assembly가 되어 있는지를 확인합니다.


Server에 추가 후, Hello World!가 나오는지 확인합니다.



이번에는 Tomcat이 아닌 jetty를 이용해서 실행해보도록 하겠습니다.
pom.xml > build > plugins 에 다음 항목을 추가합니다.

            <plugin>
                <groupId>org.eclipse.jetty</groupId>
                <artifactId>jetty-maven-plugin</artifactId>
                <version>9.0.1.v20130408</version>                
            </plugin>

추가후 mvn jetty:run 을 이용해서 jetty를 실행시켜주세요. 그리고 jetty는 이 버젼에 유의해서 사용해야지 됩니다. jetty 9.0.0 버전은 심각한 오류를 가지고 있기 때문에 절대로 사용해서는 안됩니다. 
jetty를 사용하는 경우에는 webapplication name이 없이, http://localhost:8080 으로만 접근이 가능합니다. 

Summary

maven을 이용해서 web application을 작성하는 법을 한번 알아봤습니다. maven으로 작업하는 경우에는 maven way 라고 하는 절대적인 폴더 위치를 비롯해서 프로젝트의 구성을 그대로 맞춰줘야지만 쉽게 사용할 수 있습니다. 물론, 위치들을 변경하는 방법역시 존재하지만 이와 같은 공통적인 방법을 통해서 구성하는 것이 좋습니다. 이 폴더의 구조에 대해서는 반드시 외우거나 숙지해주시길 바랍니다.


Posted by 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 Y2K
,