'01.JAVA'에 해당되는 글 214건
- 2008.07.08 Java IDL Code Samples
- 2008.07.07 MultipartRequest를 이용하여 업로드구현하기
- 2008.07.07 자바 웹 프로그래머가 알고있어야 할 기본
- 2008.07.07 java networking
★ MultipartRequest를 이용하여 업로드구현하기
|
* 관련사이트 http://www.servlets.com/cos/ COS 공식 사이트 저자 : 이선재(hsboy) |
2 발문 #
프로그래밍 초보자가 능히 한 사람 몫을 할 정도로, 혼자 코딩하도록 내버려둬도 다른 사람들이 불안에 떨지 않을 만큼 성장하는 가장 빠른 방법은 무엇일까? 디자인 패턴을 공부하고 최신 기술을 익히고 실전 프로그래밍을 많이 해보는 것? 그것도 물론 중요하다. 그러나, 이보다 훨씬 더 중요한 것은 기초를 다지는 것이다. 슬램덩크에서 강백호는 농구부 입단 후 2주일 간 드리블 연습만 했고 이것이 그가 빠른 시간 안에 한 사람 몫을 해내는데 밑거름이 되었다. 잠시 더블 클러치 연습은 멈추고 드리블을 해보자. 복잡한 이론, 어려운 신기술은 잠시 접어두고 프로그래머로서의 기본을 재점검해보자.3 필자 소개 #
박영록 refactorer@naver.com code for human, not for programmer. 인간다운 프로그래머, 게으른 프로그래머를 지향한다. 현재 NHN에서 프레임웍 개발과 서버 관리를 담당하고 있다.4 본문 #
4.1 서론, 어떻게 공부할 것인가 #
4년 전, 학교에서 어느 벤처 경영인의 강연을 들은 적이 있다. 미국에서 벤처를 시작해서 어느 정도의 성공을 거둔 기업가였다. 그는 강연 내내 기본을 강조했다. 미국과 한국의 기업 문화의 차이를 비교하면서 미국의 벤처들은 대체로 경영인으로서의 기본적으로 지켜야할 것들을 잘 지키는 반면 한국의 벤처는 기본적인 것들을 제대로 지키지 못하고 그로 인해 실패하는 경우가 많다고 했다. 벤처 붐이 일 때 수많은 학생 벤처가 경영에 대한 무지로 가진 기술을 펼쳐보지도 못하고 망한 현상에 대해 벤처는 경영이며 경영을 하려면 경영에 대해 배워야하는 것은 기본인데 그 기본이 지켜지지 않았기 때문이라고 했다. 당시 부도덕한 벤처 기업가들의 행태가 사회적으로 논란이 되고 있었는데 이에 대해서는 사회인으로서의 기본적인 소양이 갖추어져 있지 않기 때문이라고 했다. 그는 모든 것을 기본이란 말 하나로 설명했다. 기본이 물론 성공의 충분조건은 아니다. 그러나, 기본을 지키지 않고는 성공할 수 없다. 어떤 분야든 이것은 예외가 없을 것이다.4.2 본론 #
4.2.1 web.xml #
배치 서술자(deployment descriptor)라고 부르는 web.xml은 웹 프로젝트를 구성하는데 있어 필수적이면서 웹 애플리케이션의 동작을 여러 가지로 조정하는 역할을 한다. 스트러츠를 사용하는 경우도 스트러츠를 사용하기 위한 설정은 web.xml에 하게 되는데 그 설정들이 무슨 의미를 가지고 있는지 정도는 상식으로 알아두는 것이 좋을 것이다. 다음의 실제 스트러츠 설정 예제를 보자. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"><servlet> <servlet-name>action</servlet-name> <servlet-class> org.apache.struts.action.ActionServlet </servlet-class> <init-param> <param-name>config</param-name> <param-value> /WEB-INF/struts-config.xml </param-value> </init-param> <load-on-startup>1</load-on-startup></servlet><servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern></servlet-mapping></PRE>PHP, ASP 등의 다른 서버 사이드 스크립트나 JSP 페이지는 페이지를 호출하는 경로에 실제 스크립트 파일이 존재해야하지만 서블릿은 이와 달리 web.xml의 설정을 이용해서 URL을 특정 서블릿으로 매핑시킬 수 있다. 위의 설정은 호출된 URL을 스트러츠의 Action으로 매핑시키기 위한 설정이다. servlet 설정에서 action이라는 이름의 서블릿을 org.apache.struts.action.?ActionServlet 클래스로 등록하고 아래의 servlet-mapping 설정에서 *.do라는 URL로 호출된 페이지들을 action이라는 이름의 서블릿으로 매핑시킨다. url-pattern 값을 *.nhn으로 바꾼다면 *.nhn으로 호출된 요청들이 ?ActionServlet으로 매핑될 것이다. 스트러츠는 이 ?ActionServlet에서 요청을 각 Action으로 분기시켜준다. init-param은 서블릿을 초기화할 때 사용할 파라미터값이며 getInitParameter 메쏘드를 통해서 읽어올 수 있다. load-on-startup은 서블릿 엔진이 스타트될 때 로드될 우선 순위를 지정하는 값이다.4.2.2 예외 처리 #
자바의 강점 중 하나가 편리한 예외 처리 방식이다. C 언어 등 예외 처리 문법이 없는 언어를 먼저 접한 프로그래머에게는 생소한 개념일 수 있겠지만 알면 알수록 편리한 것이 자바의 예외 처리이다. 하지만 의외로 많은 자바 프로그래머들이 예외 처리를 어려워하고 예외 처리를 제대로 하지 않아 여러 가지 문제를 발생시킨다. 기본이라고 할 수도 있는 부분이긴 하나 사실 이것은 자바의 예외 처리 문법만 배운다고 되는 문제는 아니며 예외 처리에 대한 많은 고민이 필요하다. 특히 웹 애플리케이션의 예외 처리는 프로그래머를 위한 부분과 웹사이트 방문객을 위한 부분 두 가지를 모두 고려해야한다.4.2.3 로깅 #
에러 페이지에서 해야할 또 하나 중요한 일은 예외 상황에 대한 로그를 남기는 것이다. 에러 페이지까지 왔다는 것은 이미 개발자의 예상을 벗어난 동작을 하고 있다는 것이므로 이 사실은 개발자에게 빨리 전달되어야한다. 때문에 로그를 제대로 남겨서 조회하기 편한 시스템을 구축해야한다. 로깅 API는 여러 가지가 있고 JDK 자체에도 포함되어 있지만 log4j가 가장 널리 사용되고 성능, 기능, 안정성 등 여러 가지 면에서 다른 것들보다 낫다. 여러 가지 로깅 API를 바꿔가면서 사용할 수 있게 해주는 자카르타의 commons-logging 프로젝트도 쓸만하다. 로거 객체는 일반적으로 클래스 당 하나를 클래스의 전체 이름으로 생성해서 사용한다. 다음은 commons-logging을 사용하는 예다. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black">package com.hangame.avatar;import ...public class Avatar { private static Log log = LogFactory.getLog(Avatar.class); public void changeBackgroud() { log.debug("avatar changing.."); }}</PRE>이러면 로그 객체는 Avatar 클래스의 전체 이름, com.hangame.avatar.Avatar로 생긴다. 만약 여기에 log4j를 붙여서 사용한다면 다음과 같은 log4j 설정을 사용할 수 있다. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"><?xml version="1.0" encoding="UTF-8" ?><log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'> <appender name="normal" class="org.apache.log4j.ConsoleAppender"> <param name="Threshold" value="DEBUG"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} [%-5p] %m%n"/> </layout> </appender> <appender name="memory" class="com.nhn.logging.MemoryAppender" > <param name="Threshold" value="ERROR"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} [%-5p](%F:%L) %m%n"/> </layout> </appender> <logger name="com.hangame" additivity="false"> <level value="DEBUG"/> <appender-ref ref="normal"/> <appender-ref ref="memory"/> </logger> <logger name="org.apache" additivity="false"> <level value="INFO"/> <appender-ref ref="normal"/> </logger> <root> <level value="WARN"/> <appender-ref ref="STDOUT"/> </root></log4j:configuration></PRE>위의 설정은 com.hangame와 org.apache라는 이름의 로거를 두 개 생성하고 있다. 로거의 특성은 이름으로 상속된다. com.hangame.avatar.Avatar라는 이름의 로거는 com.hangame의 속성을 모두 상속 받게 된다. 그러면 com.hangame이 normal과 memory라는 두 개의 appender를 갖고 있기 때문에 com.hangame.avatar.Avatar 로거가 찍은 로그는 표준 출력으로도 나가고 메모리에도 남게 된다. log4j의 이런 특성을 이용하면 다양한 방식으로 로그를 남길 수 있고 로그를 선택적으로 켜고 끄는 것이 가능하다. 이런 기능들을 잘 활용하면 로그를 조회하기 쉽게 구성할 수 있다. 위에서 예를 든 것처럼 메모리에 최근 로그를 남겨두고 이를 조회할 수 있는 페이지를 만든다거나 데이터베이스에 로그를 쌓을 수도 있다. 그리고 주기적으로 이런 로그 조회 페이지를 모니터링하면서 로그 리포트를 개발자에게 메일 등으로 자동 발송해주는 시스템도 구상해 볼 수 있을 것이다.4.2.4 예외 추적 #
예외 처리 시스템을 구축하고 예외 로그를 남겼으면 다음은 이 정보를 바탕으로 문제점을 찾아들어가는 것이다. 예외 추적의 출발점은 당연히 예외 스택 정보이다. 대부분의 문제는 예외 스택 정보만 가지고도 찾아낼 수 있다. 하지만 의외로 많은 프로그래머들이 예외가 발생했을 때 스택 정보를 보지 않고 자신의 경험에 의지해서 문제점을 예측하려 하곤 한다. 이런 실제 상황에 기반하지 않은 예측은 운 좋게 문제를 바로 짚어내는 경우도 있겠지만 대개의 경우 시간만 낭비하게 된다. 예외가 발생하면 반드시 스택 정보에 찍힌 소스의 라인부터 살펴보는 습관을 기르는 것이 좋다. 스택 정보는 가끔 수백 라인에 이를 정도로 길어지는 경우도 간혹 있다. 이 모든 정보를 다 찾아볼 필요는 없다. 스택 정보는 메쏘드가 호출된 역순으로 찍히므로 위에 있는 정보가 예외가 발생한 위치와 가까운 정보다. 그렇다고 늘 제일 위의 정보를 봐야하는 것은 아니다. 웹 애플리케이션의 경우 스택 정보는 자신이 작성한 클래스 뿐 아니라 서블릿 엔진을 포함한 여러 가지 클래스의 정보들이 같이 담겨 있다. 이런 정보들은 보통 볼 필요가 없고 스택 정보에서 자신이 작성한 클래스 중 제일 위에 있는 것, 이것이 예외가 발생한 지점이며 이곳을 찾아보면 대부분의 문제점은 정확하게 추적 가능하다.4.2.5 한글 문제 #
웹 프로그래머들을 괴롭게 하는 문제를 꼽을 때 빠지지 않는 것이 한글 문제다. 한글 문제가 지금처럼 골치아프게 된 데는 역사적으로 복잡한 원인들이 얽혀 있는데 이런 문제는 접어두고 자바 웹 프로그래머로서 한글 문제를 해결하기 위해 알아야하는 것들을 살펴보자.4.2.6 URL 인코드 #
URL 인코딩이 필요한 것은 URL에 사용가능한 문자가 제한되어 있기 때문이다. URL 스펙(RFC 1738)에 정의된 바로는 URL에 사용할 수 있는 문자는 알파벳, 숫자와 몇 가지의 특수문자 뿐이다. 따라서 다양한 문자들을 URL로 전달하려면 URL에서 허용하는 문자로 변환시켜서 전달해야한다. 이것은 GET 요청의 파라미터로 값을 전달하려할 때 문제가 된다. 예를 들어 http://website.com/process.jsp에 로그인 안된 상태에서 접근하면 자동으로 로그인 페이지인 http://website.com/login.jsp로 리다이렉트된 후 로그인을 하면 원래 요청했던 페이지로 다시 리다이렉트되도록 해야한다고 하자. 그러면 /process.jsp에서는 로그인 페이지로 리다이렉트시키면서 파라미터로 현재 요청한 URL, 즉 /process.jsp를 넘겨주고 login.jsp에서는 로그인 처리가 끝난 후 이 URL로 다시 리다이렉트를 시키면 된다. 여기서 /process.jsp에서는 http://website.com/login.jsp?redirect=http://website.com/process.jsp와 같은 형식으로 리다이렉트를 해주면 될 것이다. 여기서 문제는 redirect 파라미터의 값이 URL이기 때문에 URL 안에 URL이 들어간 형태가 되어 제대로 파싱이 되지 않는다. 그래서 파라미터로 넘겨야하는 URL 부분을 ?URLEncoder로 인코딩을 해서 http://website.com/login.jsp?redirect=http%3A%2F%2Fwebsite.com%2Fprocess.jsp와 같은 형태로 넘겨야한다. 이 값을 받는 부분에서는 다시 디코딩을 해줄 필요가 없다. URL은 자동으로 웹 서버에서 파싱할 때 디코딩을 해주기 때문이다. URL을 통해서 GET 요청의 파라미터로 보내야하는 값은 반드시 URL 인코딩을 거쳐야한다는 사실만 기억하도록 하자. 참고로 자바스크립트에서도 escape, unescape 함수를 통해서 URL 인코딩, 디코딩과 유사한 작업을 수행할 수 있다.4.2.7 클래스패스의 리소스 사용법 #
웹 애플리케이션은 보통 애플리케이션의 설정을 담고 있는 파일이 필요하다. web.xml, struts-config.xml 등의 설정 파일들은 보통 웹 애플리케이션의 /WEB-INF/에 위치하게 되는데 그 외에 애플리케이션에서 사용하는 파일들은 어디에 놓고 사용하는 것이 편리할까? 가장 관리하기 쉽고 부가적인 작업이 적은 방법은 클래스패스에 두는 것이다. /WEB-INF/classes에 두면 자바의 클래스로더를 이용해서 이런 파일들에 접근할 수 있다. log4j 등 많은 라이브러리들이 자신의 설정 파일을 클래스패스에서 가장 먼저 찾게 된다. 다음의 예제를 보자 <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black"> public File getFile(String name) { ClassLoader loader = Thread.currentThread().getContextClassLoader(); return new File(loader.getResource(name).getFile()); } public void doSomeProcess() { File file = getFile("config.xml"); }</PRE>위의 코드는 클래스패스에서 config.xml을 읽는다. 웹 애플리케이션의 기본 클래스패스는 /WEB-INF/classes이므로 기본적으로 여기서 찾게 된다. 이것으로 jar 파일 안의 내용도 읽을 수 있다. 이 경우는 ?ClassLoader.getResourceAsStream을 통해서 스트림으로 파일 내용을 읽을 수 있다. 대부분의 IDE나 maven 등의 빌드 툴에서는 소스 경로에 있는 파일들 중 자바 소스가 아닌 파일들을 자동으로 클래스패스로 복사해주므로 이용하기도 편리하다. 자카르타의 commons-discovery 프로젝트는 이런 기능들을 모아서 편리하게 이용할 수 있게 제공하고 있다.4.2.8 서블릿/액션 멤버 변수 공유 문제 #
JSP가 보급되기 시작하던 초기에 많이 발생하던 문제로 웹사이트의 이용자가 접속했을 때 자신의 정보가 아닌 다른 사람의 정보가 나타나면서 엉키는 경우가 있었다. 이것의 원인은 서블릿에 대한 이해가 부족해서 발생한 것이었다. 다음의 예제를 보자. <PRE class=wikiSyntax style="COLOR: #c0c0c0; FONT-FAMILY: FixedSys,monospace; BACKGROUND-COLOR: black">public class BadServlet extends HttpServlet { Map userInfo; protected void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { String username = req.getParameter("name"); Map userInfo = UserManager.getUserInfo(username); req.setAttribute("userInfo", username); }}</PRE>얼핏 별 문제가 없어보이지만 이 코드는 심각한 문제가 있다. 서블릿은 보통 서블릿 엔진에서 하나만 생성되고 한 번 생성된 서블릿 객체가 계속 재활용된다. 때문에 A와 B라는 두 사용자가 동시에 이 서블릿을 호출하게 되면 A의 호출을 수행하는 중에 B의 호출이 userInfo의 값을 바꿔버릴 수 있다. 그러면 A는 B의 정보를 보거나 그 반대의 경우가 생길 수 있는 것이다. 혼자서 테스트할 때는 한 번에 한 쓰레드만 service 메쏘드를 호출하기 때문에 이런 문제가 잘 드러나지 않기 때문에 별 문제 없는 줄 알고 있다가 서비스를 오픈하고 나면 문제가 되는 경우가 있으므로 조심해야한다. JSP에서 <%! %>를 통해서 선언하는 내용도 마찬가지 문제가 발생하므로 주의하자. 이런 내용 역시 자바 클래스와 멤버 변수의 기본 개념을 이해하고 서블릿 스펙만 한 번 읽어본다면 금방 알 수 있는 내용이다.4.3 결론, 생각하기 #
이 내용들을 읽으면서 모르는 내용이 하나도 없었다면 자바 웹 프로그래머로서 어느 정도 기본은 되어 있다고 할 수 있다. 이런 내용들은 그 하나하나에 대한 지식을 쌓는 것도 중요하지만 더 중요한 것은 이런 내용을 알아야한다는 사실을 아는 것이다. 무엇을 알아야하는가를 가르쳐주는 것은 스펙이다. 스펙 문서들은 대부분 영어이고 그다지 친절하게 되어 있진 않지만 해당 분야에 대해 가장 정확한 정보를 담고 있다. 자세한 내용을 다 알진 못하더라도 스펙에 어떤 내용이 있는가 정도는 알아야 그 내용 중 자신에게 필요한 내용을 찾아서 공부할 수가 있는 것이다. 이런 정보를 어디서 찾을 수 있는가를 알고 있는 것도 중요하다. 기본적으로 www.ietf.org, jcp.org, java.sun.com, www.w3.org 정도의 사이트에는 익숙해지는 게 좋을 것이다.4.4 참조 #
- http://java.sun.com/products/servlet/download.html 서블릿
- http://jcp.org/aboutJava/communityprocess/final/jsr152/index.html JSP 2.0
- http://www.ietf.org/rfc.html RFC 홈페이지
- http://www.ietf.org/rfc/rfc2068.txt?number=2068 RFC 2068, HTTP 프로토콜
- http://www.ietf.org/rfc/rfc1738.txt?number=1738 RFC 1738, URL
- http://www.w3.org/ World Wide Web Consortium
- http://www.w3.org/TR/html4/ HTML 4.01
- http://www.w3.org/TR/xhtml1/ XHTML 1.0
- http://www.w3.org/TR/2004/REC-xml11-20040204/ XML 1.1
- http://www.w3.org/Style/CSS/ CSS
- http://trio.co.kr HTML, XHTML, CSS의 한글 번역 문서
- http://jakarta.apache.org/commons/ 자카르타 commons 프로젝트
- http://www.javaservice.net/~java/bbs/read.cgi?m=devtip&b=servlet&c=r_p&n=968185187 서블릿 인스턴스 변수 공유 문제에 대한 글