'개발하는 남자'에 해당되는 글 122건
- 2008.01.05 저의 비서를 소개합니다.(프랭클린 플래너와 파카 멀티펜) 2
- 2008.01.05 아이프레임 리사이즈 문제 해법
- 2008.01.05 멱등(Idempotent)
- 2008.01.05 Java API Map
- 2008.01.05 Head First Java (뇌 회로를 자극하는 자바 학습법)
- 2008.01.05 최범균의 JSP 2.0 프로그래밍 - 기초부터 중급까지
- 2007.12.23 [Eclipse] JVM terminated. Exit code=-1 ....................................... 3
- 2007.12.22 [담아온글] 자바 웹 프로그래머의 기본
- 2007.12.22 [JNDI] NamingException
- 2007.12.20 이클립스에서 src, classes 폴더의 위치
프랭클린 플래너 CEO와,
파카 인시그니아MF 멀티펜.
작년, 친한 선배한분이 취업선물로 플래너를 사주고 싶다고 골르라고 하더군요.
그래서 고른 녀석이 저녀석입니다.
컴팩 시리즈는 예전에 써봤었는데(잊어버렸음ㅠㅠ),
가지고 다니기엔 약간 부담스러웠던 기억이 있어서 CEO를 사야겠다고 마음먹었습니다.
얼만지는 생각하지 말라고 했지만;; 눈치를 안 볼 수 없잖아요?ㅎ
제일 싼 3만원대 바인더중에서 녹색이 들어있는 것을 찾다가 요놈을 골랐습니다.
(리필용지까지 6만원)
배송 온걸 보니 사진으로 봤을때 보다 더 맘에 들더군요^^
플래너가 생기고 나니 볼펜을 멀 꼽아야될까 고민이 되더라구요.
그냥 아무 멀티펜이나 꼽고 다닐참이였지만,
플래너에 어울리는 오래쓸 수 있는 펜을 꼽아야겠다는 생각이 들었습니다.
그래서 구매한 녀석이 파카 인시그니아MF 멀티펜.
3만 8천 약간은 부담스러운 가격이었지만
다 쓰고 심만 갈아끼면 되기 때문에(1000원),
초기에만 부담스러울 뿐 추가비용은 많이 들지 않습니다.
무엇보다도 맘에 드는건 무료 각인 서비스!!
무료로 글씨를 새겨주드라고요^^
애착이 더욱 가게끔 하네요 ㅎ
영문이름을 새길까 닉네임을 새길까 고민하다가 결국은 닉네임을 새겼는데요,
사실 영문이름을 새길껄 하는 후회가..ㅠㅠ
아무튼 앞으로 이 두녀석과 스케줄관리, 시간관리를 철저히 해볼 생각입니다.
돈을 많이 쏟아 부었으니 안할래야 안할수가 없겠죠? ^^
참고 - 구매한 곳.
- 한국리더쉽센터(http://www.eklc.co.kr/www/shop/shop/mall_main.asp)
- 베스트펜(http://www.bestpen.co.kr/)
'Reviews' 카테고리의 다른 글
| 샤프전자 PMP딕 SP600 짧막한 개봉기.. (0) | 2008.05.29 |
|---|---|
| [노트북] 후지쯔 S6510 - 나름의 후기 (0) | 2008.04.27 |
| 공짜폰 SKY IM-U220(돌핀폰) 후기 (0) | 2008.01.26 |
How To Resize an IFrame to the Size of Its Contents Without Displaying Scroll Bars
| Article ID | : | 278469 |
| Last Review | : | November 23, 2006 |
| Revision | : | 4.1 |
SUMMARY
MORE INFORMATION
The following code demonstrates how to resize an IFrame in this way. Create a new .htm document, and paste the following HTML code. In the SRC attribute for the IFrame, you must supply an HTML page from the same domain that the IFrame loads.
NOTE: This technique may not work correctly if there are absolutely positioned elements that are residing within the IFrame.
<HTML>
<HEAD>
<SCRIPT LANGUAGE=javascript>
<!--
function reSize()
{
try{
var oBody = ifrm.document.body;
var oFrame = document.all("ifrm");
oFrame.style.height = oBody.scrollHeight +
(oBody.offsetHeight - oBody.clientHeight);
oFrame.style.width = oBody.scrollWidth +
(oBody.offsetWidth - oBody.clientWidth);
}
//An error is raised if the IFrame domain !=
its container's domain
catch(e)
{
window.status = 'Error: ' + e.number + '; ' + e.description;
}
}
//-->
</SCRIPT>
</HEAD>
<BODY onload=reSize()>
<iframe onresize=reSize() id=ifrm src=YOUR_PAGE_HERE></iframe>
</BODY>
</HTML>
This example uses try and catch to check for domain consistency, which are only available with Internet Explorer 5 and later. This error checking is included for illustration purposes and is not absolutely necessary; it only allows the script to fail gracefully.Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose. This article assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures. Microsoft support professionals can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific needs. If you have limited programming experience, you may want to contact a Microsoft Certified Partner or the Microsoft fee-based consulting line at (800) 936-5200. For more information about Microsoft Certified Partners, please visit the following Microsoft Web site:
REFERENCES
http://support.microsoft.com/iep (http://support.microsoft.com/iep)
'작업노트 > HTML & Script' 카테고리의 다른 글
| 프레임구조에서 전체화면에 링크 반영하기 (0) | 2008.08.26 |
|---|---|
| 전체선택을 위한 자바스크립트 코드 (0) | 2008.02.02 |
| name과 id의 차이 (0) | 2007.09.15 |
| GET방식으로 한글 보내는 방법 (0) | 2007.09.04 |
| innerHTML을 사용할 시에 (0) | 2007.08.29 |
멱등은 동일한 작업을 어떤 부작용도 없이 한 번이고 두 번이고 계속해서 할 수 있다.
멱등이라는 말은 여러가지 의미로 사용된다. HTTP/서블릿 환경에서 이 말은 동일 요청은 서버에 어떤 잘못된 결과를 야기하지 않고 두 번이상 이루어질 수 있다는 의미이다. 동일 요청은 동일 응답을 가져야 한다는 의미가 아님을, 요청으로 어떤 부작용도 발생하지 말아야 한다는 의미가 아님을 유의해야 한다.
HTTP 스펙 1.1에서는 GET, HEAD, PUT은 멱등이라고 정의하고 있다. 물론 개발자가 멱등이 아닌 doGet()을 작성할 수도 있지만 권장되지는 않는다. POST는 HTTP 스펙 1.1에 의하면 멱등이 아니다.
HTTP GET은 말 그대로 무엇인가를 서버로부터 가져오는 것이지, 서버에 수정을 가하기 위한 것이 아니다. GET은 HTTP 스펙에 따르면 멱등 메소드이다. GET은 어떤 부작용(bad side effect)없이 여러 번 실행할 수 있다.
POST는 반대로 멱등 메소드가 아니다. POST로 전송되는 몸체의 정보는 트랜잭션을 위한 것이면, 이는 되돌릴 수 있는 성질의 것이 아니다. 이런 이유 때문에 doPost()를 구현할 때 유의해야 한다.
-HEAD FIRST Servlet & JSP
'작업노트 > JSP & Servlet' 카테고리의 다른 글
| 커스텀 태그 라이브러리 사용시 (0) | 2008.10.09 |
|---|---|
| 스코프(Scope) (0) | 2007.11.19 |
| [미해결] 이미지 태그 한글 파일명 경로 처리문제 (0) | 2007.09.04 |
| request.getSession() (0) | 2007.05.27 |
| JspWriter (0) | 2007.05.27 |
'작업노트 > JAVA' 카테고리의 다른 글
| CSV파일 (0) | 2009.03.02 |
|---|---|
| 자바 5 에서의 반복자와 컬렉션(for/in 반복문) (0) | 2008.02.28 |
| JVM 메모리구조와 스택 - 참조 ^^ (0) | 2007.11.19 |
| 자바에서 swap 구현하기 (0) | 2007.11.19 |
| Vector or ArrayList -- which is better? (0) | 2007.05.29 |
신선한 책이다.
부제목의 문구대로 뇌 회로를 확실히 자극시켜준다.
웹쪽으로 진로를 정하면서 자바를 공부하기 위해 책을 고르던중,
재미있다는 서평들을 읽고 빨리 읽을 수 있을 것 같아 고른 책이다.
이런 이론서들은 대부분 지루하기 짝이 없다는 건 누구나 다 겪어봐서 잘 알것이다.
하지만 이 책은, 공부하다가 뇌의 구동이 멈추려 할때면 신선한 바람을 공급해준다.
읽어보면 알 것이다.
나는 끝까지 읽는데에 2주 정도 걸렸다.
(하루에 7-8시간씩 매달린것 같다. 매주 4일 공부했으니..64시간정도 걸린 듯)
책 구성이 색다르고 신선했기에 지치지 않고 공부할 수 있었다.
자바를 공부하고 싶은 사람들에게 정말 강추하고 싶은 책이다.
단, 플밍 경험, 객체지향의 개념이 조금이라도 있어야지 읽기에 수월할 것 같다.
가끔... 그런 부분들이 나온다.
'작업노트 > Books' 카테고리의 다른 글
| 최범균의 JSP 2.0 프로그래밍 - 기초부터 중급까지 (0) | 2008.01.05 |
|---|
회사에서 신입교육 교제를 고르라기에;; 어떤 걸 사야되나 고민했는데
동기가 사자고 해서 고른 책.
요즘 나오는 서블릿/jsp책들은 책 제목 부터 알 수 있듯이 mvc패턴을 중심으로 쓰여져있다.
즉, jsp는 책의 일부일 뿐이라는 얘기.
하지만 이 책은 JSP만을 중점적으로 다루고 있는 책이었다.
사실 jsp의 기능들을 제대로 모르고(어떤걸 어떤때에 써야겠다는 생각조차도 없었다.)
사용한 경우가 많았는데, 이번에 다시한번 이 책을 읽어 보면서 간과할 수 없는
jsp의 기능들을 많이 익힐 수 있었다.
JSP에 대해서 자세하게 알고 싶은 분께 추천하고 싶은 책.
책이 오래되었고, jsp위주이다 보니 요즘 트렌드에 맞추자면,
다른 servlet/jsp책도 같이 봐야 좋을 것같다.(열혈강의 시리즈 추천)
단점이 있다면...
예제가 돌아가지 않는게 있다 -_-;;
방명록 예제에서 페이징처리 부분이 그러하다. 나는 그전에 해놓은 소스로 대체 했지만,
다른 동기분들은 꽤 귀찮은 작업이었을 듯 ㅎ
또... 너무 저자의 스타일이 녹아든 예제들이 아니었나..
물론, 그건 책쓴사람 마음이고 어쩔수 없는 것이지만,
그에 대한 설명이 있었더라면 책을 이해하는데 좋았지 않겠었나 싶다.
마음대로 본문에도 없는 내용 가져다 써놓고 머하는 건지, 왜 썼는지에 대한
설명이 없어서 아쉬웠다.
그리고 문필능력이랄까? 이해시키는 문장력이 부족하신듯 하다.
쉽게 설명할 수 있는 내용을 베베베 꼬아서 써놓은 경향이 있다.
저자의 최근 저서들은 본적이 없어 모르겠지만, 꽤나 영향력 있으신 분이니
문장실력을 좀더 키워서 좋은 책들, 많이 써주었으면 한다.
'작업노트 > Books' 카테고리의 다른 글
| Head First Java (뇌 회로를 자극하는 자바 학습법) (0) | 2008.01.05 |
|---|
[Eclipse] JVM terminated. Exit code=-1 .......................................
| 작업노트/Error Handling 2007. 12. 23. 12:25컴퓨터를 포맷하고 새롭게 개발환경을 구축하던중에
이클립스를 설치하고 실행하려할 때
JVM terminated. Exit code=-1
.........................
..........(중략)........
..........................
-Xms40m
-Xms512m
이런 류의 경고창이 튀어나왔다.
정확한 답을 찾을 수는 없었지만 메모리 설정에 문제가 생긴 듯 하다.-_-
eclipse가 설치된 폴더에서 eclipse.ini 파일을 연 후
-Xms40m
-Xms512m
이라고 되있는 부분을
-Xms128m
-Xms256m
이라고 고친 후 실행시키면 된다.
'작업노트 > Error Handling' 카테고리의 다른 글
| Context [] startup failed due to previous errors.... 등등; (0) | 2008.05.29 |
|---|---|
| The method getJspApplicationContext(ServletContext) is undefined for the type JspFactory (6) | 2008.02.19 |
| [JNDI] NamingException (0) | 2007.12.22 |
| [Eclipse] Resource is out of sync with the file system : ... (1) | 2007.12.18 |
| 서블릿을 사용할 경우 js파일 경로 (0) | 2007.09.07 |
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에 하게 되는데 그 설정들이 무슨 의미를 가지고 있는지 정도는 상식으로 알아두는 것이 좋을 것이다. 다음의 실제 스트러츠 설정 예제를 보자.<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>
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은 서블릿 엔진이 스타트될 때 로드될 우선 순위를 지정하는 값이다. <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list>태그명에서 짐작할 수 있듯이 인덱스 페이지는 여러 개를 둬서 순서대로 검색하게 할 수 있다. 예를 들어 index.html과 index.jsp가 순서대로 지정된다면 서블릿 엔진은 index.html이 있으면 index.html을 보여주고 없으면 index.jsp를 호출한다. 이것도 없으면 404 에러가 나거나 디렉토리 목록이 보이게 된다. 이 인덱스 페이지는 모든 경로에 대해서 동작한다. 위와 같은 설정의 경우 http://www.hangame.com/login/을 호출한다면 http://www.hangame.com/login/index.jsp를 찾게 되는 것이다. 이 설정은 사실 아파치 등의 웹서버에서도 해줄 수 있으나 보통 웹 서버에서는 인덱스 페이지가 실제 파일로 존재해야 보여줄 수 있는데 서블릿 엔진에서는 실제 파일로 존재하지 않고 서블릿 매핑으로 지정만 되어 있어도 보여줄 수 있다는 장점이 있다.
<security-constraint>
<web-resource-collection>
<web-resource-name>retail</web-resource-name>
<url-pattern>/acme/retail/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>CONTRACTOR</role-name>
<role-name>HOMEOWNER</role-name>
</auth-constraint>
</security-constraint>
위의 예는 서블릿 스펙 문서에 있는 예다. 이것의 의미는 GET이나 POST로 /retail/*와 같은 요청은 CONTRACTOR와 HOMEOWNER라는 role을 가진 사용자에게만 허락하겠다는 뜻이다. 이외의 사용자는 권한이 없다는 401 에러 페이지를 보게 된다. 이런 접근 제한 뿐 아니라 로그인 처리도 login-config 설정을 이용하면 가능하다. 실제 톰캣의 admin과 manager 애플리케이션은 이 설정을 이용해서 인증과 권한 처리를 한다. 자세한 스펙은 서블릿 스펙 문서에 정의되어 있으나 실제 활용하기엔 다소 부족한 감이 있고 톰캣의 실제 활용 예를 보는 것이 도움이 될 것이다. 이외에도 서블릿 필터 설정, 세션 설정, 리소스 설정 등 여러 가지 유용한 설정을 해줄 수 있고 공통적인 에외 처리를 위한 에러 페이지 설정도 가능하다. 에러 페이지 설정 부분은 이후 예외 처리에서 자세히 다룰 것이다. 4.2.2 예외 처리 #
자바의 강점 중 하나가 편리한 예외 처리 방식이다. C 언어 등 예외 처리 문법이 없는 언어를 먼저 접한 프로그래머에게는 생소한 개념일 수 있겠지만 알면 알수록 편리한 것이 자바의 예외 처리이다. 하지만 의외로 많은 자바 프로그래머들이 예외 처리를 어려워하고 예외 처리를 제대로 하지 않아 여러 가지 문제를 발생시킨다. 기본이라고 할 수도 있는 부분이긴 하나 사실 이것은 자바의 예외 처리 문법만 배운다고 되는 문제는 아니며 예외 처리에 대한 많은 고민이 필요하다. 특히 웹 애플리케이션의 예외 처리는 프로그래머를 위한 부분과 웹사이트 방문객을 위한 부분 두 가지를 모두 고려해야한다.<error-page> <exception-type>java.lang.Exception</exception-type> <location>/common/error.jsp</location> </error-page> <error-page> <error-code>404</error-code> <location>/common/error.jsp</location> </error-page>이렇게 설정해두면 웹 애플리케이션 전반에서 발생하는 예외 중 java.lang.Exception을 상속한 예외는 모두 잡혀서 /common/error.jsp 페이지에서 처리하게 된다. 예외가 발생하면 request 객체에 예외 상황에 대한 정보가 attribute로 저장된 후 /common/error.jsp로 포워딩되어 이곳에서 request에 담긴 정보들을 바탕으로 에외 처리를 해줄 수 있다. 이 곳에서는 일반적인 에러 메시지를 사용자에게 보여주면 된다. 자바 예외 뿐 아니라 HTTP 에러 코드도 잡아낼 수 있다. 이를테면 없는 페이지를 호출해서 404 에러가 나는 경우 이를 잡아서 페이지가 없다는 에러 메시지를 좀더 친절한 메시지로 보여줄 수 있다. 덧붙여, 이 에러 처리 페이지는 가급적 순수한 서블릿으로 만드는 것이 좋다. 스트러츠의 Action으로 에러 페이지를 구성해본 적이 있었는데 설정 상의 문제로 스트러츠의 ?ActionServlet 로딩이 실패할 경우 예외를 제대로 표시하지 못한다. JSP로 만드는 것도 나쁘진 않으나 복잡한 로직이 들어갈수록 서블릿이 더 코딩하기 더 편할 수 있다. 만약 이 에러페이지 자체에서 또다시 예외가 발생하면 찾기 힘든 경우가 많기 때문에 주의를 많이 기울여야한다.
4.2.3 로깅 #
에러 페이지에서 해야할 또 하나 중요한 일은 예외 상황에 대한 로그를 남기는 것이다. 에러 페이지까지 왔다는 것은 이미 개발자의 예상을 벗어난 동작을 하고 있다는 것이므로 이 사실은 개발자에게 빨리 전달되어야한다. 때문에 로그를 제대로 남겨서 조회하기 편한 시스템을 구축해야한다. 로깅 API는 여러 가지가 있고 JDK 자체에도 포함되어 있지만 log4j가 가장 널리 사용되고 성능, 기능, 안정성 등 여러 가지 면에서 다른 것들보다 낫다. 여러 가지 로깅 API를 바꿔가면서 사용할 수 있게 해주는 자카르타의 commons-logging 프로젝트도 쓸만하다. 로거 객체는 일반적으로 클래스 당 하나를 클래스의 전체 이름으로 생성해서 사용한다. 다음은 commons-logging을 사용하는 예다.package com.hangame.avatar;
import ...
public class Avatar {
private static Log log = LogFactory.getLog(Avatar.class);
public void changeBackgroud() {
log.debug("avatar changing..");
}
}
이러면 로그 객체는 Avatar 클래스의 전체 이름, com.hangame.avatar.Avatar로 생긴다. 만약 여기에 log4j를 붙여서 사용한다면 다음과 같은 log4j 설정을 사용할 수 있다. <?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>위의 설정은 com.hangame와 org.apache라는 이름의 로거를 두 개 생성하고 있다. 로거의 특성은 이름으로 상속된다. com.hangame.avatar.Avatar라는 이름의 로거는 com.hangame의 속성을 모두 상속 받게 된다. 그러면 com.hangame이 normal과 memory라는 두 개의 appender를 갖고 있기 때문에 com.hangame.avatar.Avatar 로거가 찍은 로그는 표준 출력으로도 나가고 메모리에도 남게 된다. log4j의 이런 특성을 이용하면 다양한 방식으로 로그를 남길 수 있고 로그를 선택적으로 켜고 끄는 것이 가능하다. 이런 기능들을 잘 활용하면 로그를 조회하기 쉽게 구성할 수 있다. 위에서 예를 든 것처럼 메모리에 최근 로그를 남겨두고 이를 조회할 수 있는 페이지를 만든다거나 데이터베이스에 로그를 쌓을 수도 있다. 그리고 주기적으로 이런 로그 조회 페이지를 모니터링하면서 로그 리포트를 개발자에게 메일 등으로 자동 발송해주는 시스템도 구상해 볼 수 있을 것이다.
4.2.4 예외 추적 #
예외 처리 시스템을 구축하고 예외 로그를 남겼으면 다음은 이 정보를 바탕으로 문제점을 찾아들어가는 것이다. 예외 추적의 출발점은 당연히 예외 스택 정보이다. 대부분의 문제는 예외 스택 정보만 가지고도 찾아낼 수 있다. 하지만 의외로 많은 프로그래머들이 예외가 발생했을 때 스택 정보를 보지 않고 자신의 경험에 의지해서 문제점을 예측하려 하곤 한다. 이런 실제 상황에 기반하지 않은 예측은 운 좋게 문제를 바로 짚어내는 경우도 있겠지만 대개의 경우 시간만 낭비하게 된다. 예외가 발생하면 반드시 스택 정보에 찍힌 소스의 라인부터 살펴보는 습관을 기르는 것이 좋다. 스택 정보는 가끔 수백 라인에 이를 정도로 길어지는 경우도 간혹 있다. 이 모든 정보를 다 찾아볼 필요는 없다. 스택 정보는 메쏘드가 호출된 역순으로 찍히므로 위에 있는 정보가 예외가 발생한 위치와 가까운 정보다. 그렇다고 늘 제일 위의 정보를 봐야하는 것은 아니다. 웹 애플리케이션의 경우 스택 정보는 자신이 작성한 클래스 뿐 아니라 서블릿 엔진을 포함한 여러 가지 클래스의 정보들이 같이 담겨 있다. 이런 정보들은 보통 볼 필요가 없고 스택 정보에서 자신이 작성한 클래스 중 제일 위에 있는 것, 이것이 예외가 발생한 지점이며 이곳을 찾아보면 대부분의 문제점은 정확하게 추적 가능하다. if ("Y".equals(param)) doSomthing();
else doOther();
이런 코드는 조심해서 써야한다. param의 null 체크가 귀찮아서 이런 식의 코드를 쓰곤 하는데 만약 param의 값이 Y인 경우는 doSomething()을 실행하고 N이나 null이면 doOther()를 실행해야하는 경우라면 이 코드는 문제가 없다. 그러나, 만약 param은 null이면 안되는 상황이라면 어떻게 될까? 다른 부분의 버그로 param에 null이 들어와도 프로그래머는 이것을 알아차리지 못하고 넘어가게 된다. 즉, 버그를 은폐하는 코드가 된다. 당장의 문제를 발생하지 않더라도 이런 코드는 나중에 찾기 힘든 문제를 유발할 수 있다. 이런 경우는 그냥 ?NullPointerException이 발생하도록 내버려 두면 param에 null 값이 들어왔을 때 다른 부분에 버그가 있기 때문이라는 사실을 감지할 수 있다. 상황에 따라 위와 같은 코드를 써도 되는지를 신중히 검토한 후 사용해야한다. 예외 발생이 두려워서 버그를 은폐할 수 있는 코드를 만들지 말자. 4.2.5 한글 문제 #
웹 프로그래머들을 괴롭게 하는 문제를 꼽을 때 빠지지 않는 것이 한글 문제다. 한글 문제가 지금처럼 골치아프게 된 데는 역사적으로 복잡한 원인들이 얽혀 있는데 이런 문제는 접어두고 자바 웹 프로그래머로서 한글 문제를 해결하기 위해 알아야하는 것들을 살펴보자.<meta http-equiv="Content-Type" content="text/html;charset=euc-kr" />여기서 지정하는 charset은 원칙적으로는 당연히 웹 서버에서 응답 객체를 생성할 때 지정한 인코딩값과 같아야 제대로 한글로 읽을 수 있다. 그러나, 여기 지정하는 charset이 RFC 표준 문자셋이 아닐 경우 브라우저에 따라 인식을 못할 수도 있다. 그래서 ?MS949로 인코딩했다면 ?MS949를 지정해야 정상이지만 ?MS949가 RFC 표준이 아니기 때문에 문제가 생길 수 있다. 그렇다고 응답의 인코딩을 EUC-KR로 지정하게 되면 확장 한글을 표시할 수 없기 때문에 문제가 된다. 그래서 페이지 인코딩은 ?MS949로 하지만 Content-Type에는 euc-kr을 지정해주게 되는 것이다. 물론 이렇게 되면 경우에 따라 확장 한글이 깨질 수 있지만 다행스럽게도 대부분의 브라우저에서 이렇게 지정하면 잘 동작한다.
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 등 많은 라이브러리들이 자신의 설정 파일을 클래스패스에서 가장 먼저 찾게 된다. 다음의 예제를 보자 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");
}
위의 코드는 클래스패스에서 config.xml을 읽는다. 웹 애플리케이션의 기본 클래스패스는 /WEB-INF/classes이므로 기본적으로 여기서 찾게 된다. 이것으로 jar 파일 안의 내용도 읽을 수 있다. 이 경우는 ?ClassLoader.getResourceAsStream을 통해서 스트림으로 파일 내용을 읽을 수 있다. 대부분의 IDE나 maven 등의 빌드 툴에서는 소스 경로에 있는 파일들 중 자바 소스가 아닌 파일들을 자동으로 클래스패스로 복사해주므로 이용하기도 편리하다. 자카르타의 commons-discovery 프로젝트는 이런 기능들을 모아서 편리하게 이용할 수 있게 제공하고 있다. 4.2.8 서블릿/액션 멤버 변수 공유 문제 #
JSP가 보급되기 시작하던 초기에 많이 발생하던 문제로 웹사이트의 이용자가 접속했을 때 자신의 정보가 아닌 다른 사람의 정보가 나타나면서 엉키는 경우가 있었다. 이것의 원인은 서블릿에 대한 이해가 부족해서 발생한 것이었다. 다음의 예제를 보자.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);
}
}
얼핏 별 문제가 없어보이지만 이 코드는 심각한 문제가 있다. 서블릿은 보통 서블릿 엔진에서 하나만 생성되고 한 번 생성된 서블릿 객체가 계속 재활용된다. 때문에 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 서블릿 인스턴스 변수 공유 문제에 대한 글
'거미줄세상' 카테고리의 다른 글
| URI? URL? URN? (0) | 2008.02.20 |
|---|---|
| 제9회 한국 자바 개발자 컨퍼런스 (0) | 2008.02.03 |
| 창조경영!! 기업블로그로 무장하라 - (주) 네트빌 (0) | 2007.12.20 |
| GET과 POST 차이 (0) | 2007.11.19 |
| 2007 JCO 오픈소스 컨퍼런스 (0) | 2007.09.26 |
JNDI 설정으로 오라클 resource를 사용 하려했을 때 네이밍 예외가 발생하였다.
server.xml 파일을 찾기 위해 톰캣을 설치한 폴더의 server.xml에서 resource를 등록하고
실행을 하였더니 아래와 같은 에러가 발생하였다.
이유인 즉슨, 이클립스에서는 서버(톰캣 등)에 대한 설정들을 별도로 관리하고 있기 때문에
톰캣 폴더의 server.xml에 등록을 하여도 반응을 하지 않는다.
server.xml 파일의 수정은 이클립스의 관리를 받는 녀석한테서 이루어져야 한다.
이클립스의 Project Explorer에서 Servers항목을 열어보면 서버관련 설정파일을 볼 수 있다.
필요에 따라 수정, 등록을 하고 서버를 재가동 시키면 된다.
(때에 따라 곧바로 반영이 안될때가 있는데, 이클립스를 닫았다가 다시 실행하면 된다.)
또는, 자신의 workspace안에 있는 Servers 폴더를 열어서 수정해주어도 된다.
2007. 12. 22 오후 12:10:22 org.apache.catalina.core.StandardWrapperValve invoke
심각: Servlet.service() for servlet jsp threw exception
javax.naming.NamingException
at com.netville.njdf.connector.DBConnector.getDataSource(Unknown Source)
at com.netville.njdf.connector.DBConnector.getConnection(Unknown Source)
at org.apache.jsp.testOracle_jsp._jspService(testOracle_jsp.java:60)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:331)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Unknown Source)
'작업노트 > Error Handling' 카테고리의 다른 글
| The method getJspApplicationContext(ServletContext) is undefined for the type JspFactory (6) | 2008.02.19 |
|---|---|
| [Eclipse] JVM terminated. Exit code=-1 ....................................... (3) | 2007.12.23 |
| [Eclipse] Resource is out of sync with the file system : ... (1) | 2007.12.18 |
| 서블릿을 사용할 경우 js파일 경로 (0) | 2007.09.07 |
| 404 - Servlet action is not available (0) | 2007.07.05 |
<--- 이클립스로 개발할때 폴더 위치.
이렇게 폴더구조를 맞추지 않으면 자동 컴파일도 안되고
그냥 컴파일도 안되고 프롬프트 창에서 컴파일 해야한다;
즉 일반환경에서의 폴더를 그대로 복사해서 붙여넣기 하면안된다.
붙여넣기를 하더라도-_-
폴더 구조에 맞게 해줘야 한다.
'작업노트 > IDE' 카테고리의 다른 글
| IDE 대세는 넷빈즈.. (0) | 2007.05.29 |
|---|---|
| [JSP] The taglib directive below imports the JSTL library (0) | 2007.05.27 |
Back to the top

