IT/모바일
저자: 이아스님(http://iasandcb.hihome.com)
무료 공개 UML 도구 ArgoUML
공식 사이트는 http://argouml.tigris.org/라네요. 저처럼 돈없는 UML그리고 싶은 사람에게는 참으로 고마운 존재가 아닌지... 실제로 돌려보니 간단하고도 쓸만하기도 하더군요. 클래스도와 유즈 케이스도도 한번 그려봤습니다.
Launch ArgoUML 0.10 using Java Web Start를 누르면 자바 웹 스타트로 바로 뜨기 때문에(J2SE 1.4 SDK 혹은 RE 필수) 따로 다운로드-설치 과정 필요없이 편하게 쓸 수 있습니다.
Date 클래스에 대한 기구한 사연
게시판 과제를 학생들에게 내었더니 SQL의 date타입을 자바에서 뭘로 처리해야 하는지를 많이 궁금해 하시더군요. 문자열로도 많이 처리하지만 원칙적으로 대응하는 것은 java.sql.Date입니다. 그런데 이 클래스(그리고 부모클래스인 java.util.Date)에는 다음과 같은 사연이 있습니다.
Prior to JDK 1.1, the class Date had two additional functions. It allowed the interpretation of dates as year, month, day, hour, minute, and second values. It also allowed the formatting and parsing of date strings. Unfortunately, the API for these functions was not amenable to internationalization. As of JDK 1.1, the Calendar class should be used to convert between dates and time fields and the DateFormat class should be used to format and parse date strings. The corresponding methods in Date are deprecated. - java.util.Date 클래스의 API문서에서 발췌.
무슨 뜻인고 하니, JDK 1.1 이전에는 Date 클래스로 연, 월, 일, 시, 분, 초, 날짜를 처리하고 문자열을 날짜로 주고받는 것도 했는데 이 Date 클래스가 국제화 처리를 위해 수정하기가 힘들어 JDK 1.1부터 Calendar가 날짜 관리, DateFormat이 문자열-날짜 처리를 하는 식으로 이원화되었다는 것입니다. 따라서 Calendar, DateFormat으로 이관된 메소드에 해당하는 Date 메소드는 비추천으로 찍혔습니다.
굳이 국제화에 신경 쓸 필요가 없다면 Date를 그대로 쓰셔도 무방하지만 세계화의 시대에 살고 있는 현대인이라면 Calendar로 쓰시기 바랍니다. 또 모르죠! 여러분이 짠 프로그램이 외국의 대학으로 수출될지. ^^ Date에서 Calendar를 얻어오는 방법은 의외로 쉬습니다.
무엇이 널일까요?
br[i]과 같이 배열의 원소를 접근하는 곳에서 NullPointerException이 나면 다음과 같은 두 가지 가능성이 있음을 생각하시기 바랍니다. 첫 번째는 br의 i번째 원소에 인스턴스가 할당되어 있지 않은 경우(원소가 null인 경우), 두 번째는 br 배열 자체가 공간 할당이 되어 있지 않은 경우(배열이 null인 경우)가 있습니다. 이점 유념하셔서 디버깅시에 고려하시기 바랍니다.
MySQL과 톰켓의 JNDI DataSource적 연동의 글 갱신
제가 2001년 12월 11일짜로 쓴 스타벅스 글(2001-12-10~2001-12-16 소식)에서
이유인 즉, org.gjt.mm.mysql.MysqlDataSourceFactory, org.gjt.mm.mysql.MysqlDataSource등의 JDBC 2.0 확장 구현 클래스들의 패키지가 org.gjt.mm.mysql에서 org.gjt.mm.jdbc2.optional로 더욱 세분화되어 있었습니다.
그런데 MysqlDataSource의 소스코드를 보니 그냥 써가지고는 커넥션 풀링이 일어나지 않더군요. 그렇다면 이 난관을 어떻게 해져 나가야 하는가? 대답은 간단하게도 org.gjt.mm.mysql.jdbc2.optional.MysqlConnectionPoolDataSource 클래스를 쓰면 됩니다. (참고로 MysqlConnectionPoolDataSource는 MysqlDataSource를 확장하고 ConnectionPoolDataSource를 구현했더군요) 그래서 다음과 같이 위의 원문을 수정합니다.
먼저 server.xml쪽은
자바 공식 사이트 개편에 대해
썩 나쁘지는 않는데 새로운 기술을 일목요연하게 보여주는 페이지가 꽁꽁 숨어버렸군요. 대신 "Recent Release"라는 이름을 가진 페이지가 새롭게 생겼습니다. 링크는 바로 여기 입니다.
JMX 책 소개
이미 오라일리에서도 『Java Management Extensions』이라는 책이 이미 출간되었듯이 매닝에서도 『JMX In Action』 이라는 책을 출간하여 서버사이드닷컴(serverside.com)에서 일반인의 검토 참여를 유도하고자 공개하고 있습니다. 톰켓 4.1을 비롯해서 앞으로의 웹 애플리케이션 서버가 거의 채택할(J2EE1.4에서는 기본) JMX 기술에 대한 논의가 벌써부터 뜨거운 느낌입니다.
J2EE Application Deployment and Management의 Spec과 RI 등장!
각각 JSR-88과 77에서 연구되었던 기술이 http://java.sun.com/j2ee/tools/deployment/와 http://java.sun.com/j2ee/tools/management/로 정식 공개되어 스펙 관련 문서 참조 구현이 나왔습니다. 그동안 J2EE 애플리케이션의 배치와 관리 기술에 표준이 없어 WAS별로 다르게(proprietary) 돌아가던 것을 통합하는 데 어떤 기여를 할지 기대됩니다. 특히 참조 구현체는 포르테 커뮤니티 에디션과의 결합도 지원하므로 (무료) 개발시에 도움이 될 것입니다.
CLDC 1.0 HotSpot - 2.5G 이동통신을 위한 자바 플랫폼
아주 우연치 않게 CLDC 1.0 문서 사이트에서 위와 같은 PDF 팜플렛을 보게 되었습니다. 아직 CLDC 1.1의 스펙과 단말기 둘 다 완전하게 발표되지 않은 상황이지만 차세대와 현세대의 간격을 메우기 위한 포석이라고 보여집니다. 특히 이동통신 기술의 발전과 더불어 대역폭이 증가하면서 더욱 더 강력한 자바 애플리케이션을 요구하는 시장의 요구에 부응하는 길이기도 하겠지요. 기본적으로 J2SE의 핫스팟 철학을 그대로 계승하면서 CLDC의 현실적 제약을 극복하는 데에 초점이 맞춰져 있습니다. 과연 플랫폼 구현자들이 강력한 암(ARM) CPU와 충분한 메모리를 통해 CLDC 1.0 핫스팟 머신을 만들어낼지 기대가 됩니다.
Java Pet Store Demo 1.3.1 - 팻스토어가 웹 서비스로 다시 태어난다?
이 데모는 http://developer.java.sun.com/developer/releases/petstore/index.html에 가면 받을 수 있습니다. 썬이 탑 페이지에 대대적으로 홍보까지 하는데 과연 어떠한 바람이 불지... 저도 이번 달 20일에 하는 자바 웹 서비스 공개 세미나에서 계획했던 예제대신 이것을 보여드려야 할지도 모르겠습니다.
Java 3D 1.3 공개
http://java.sun.com/products/java-media/3D/에서 스펙과 구현체를 받으실 수 있습니다. J2SDK 1.4와도 잘 돌아가고, 디렉트X 8.0이상에서 아주 좋습니다. (저는 사정상 OpenGL판을 쓰지만요.) 이제부터 『생생한 게임 개발에 꼭 필요한 기본 물리』의 예제(Win32-C계열로 되어 있음)를 자바로 포팅하는 프로젝트인 "애플(Apple-이 코드명의 유래는 프로젝트 공식 사이트에 있음)"을 정식으로 시작할 수 있게 되었습니다. 더불어 JSR-189로 Java 3D 1.4 연구가 시작되었습니다. 여러분들의 많은 관심 바랍니다.
자바 웹 애플리케이션의 얼굴-JSF(JavaServer Faces) 드디어 모습을 드러내다!
하지만 안타깝게도 JSR-127 EG(Expert Group)과 JCP 회원에 한해서입니다. 현재 조직 내 검토(Community Review) 1차 초안으로서 CR치고는 비교적 상세한 스펙을 자랑합니다. 다음 세대의 자바 웹 개발의 비전을 엿볼 수 있는 몇 가지 용어를 살짝 소개해드리죠.
그것은 아니라고 봅니다. 이 시점에서, 그리고 앞으로의 시점에서 중요한 것은, 자신에게 맡겨진 즉 책임을 지는 임무에 어떠한 역할을 적용하고 그 역할을 수행할 때 어떠한 기술과 상황 판단력이 필요한지를 잘 아는 것이 아닐까요? 히딩크 감독의 "모든 포지션 다 가능하기" 전략은 비단 한국 축구의 4강 신화에만 필요한 것은 아니지 않을까... 오히려 지금까지 애매한 책임전가식의 "역할 분담"이 새로운 국면을 맞이하는 데에 위의 개념들이 도움이 되기를 바랍니다.
아! 참고로 JSF은 서블릿 2.3(고로 JSP 1.2)에 기반하고 있습니다. JSTL은 한단계 더 낮은 서블릿 2.2(JSP 1.1)까지 포용하고 있죠. 물론 JSF와 JSTL은 올 하반기에 출시예정인 J2EE 1.4에 기본 사양으로 들어갈 것이지만 이렇게 새로운 시장만을 염두에 둔 것이 아니라, 현재 많이 쓰이고 있는 자바 웹 환경으로부터의 마이그레이션(사이트 개편, 향상 등의 프로젝트)이라는 기존 시스템으로부터 파생되는 수요도 감안하고 있는 "두 마리 토끼를 다 잡아보겠다"는 야심찬 첫걸음입니다. 과연 JSF와 JSTL(그리고 포틀릿(Portlet)까지)이 2002년 여름이후의 웹 개발을 바꾸어 놓을지, 의외로 그 시간은 얼마 걸리지 않을 수도 있습니다.
Ant 1.5 발표
http://jakarta.apache.org/ant/index.html가 공식 사이트입니다. 곧 공식 개시를 발표할 "퍼펙트 JSP 2판 제작 프로젝트-코드 네임 인빈서블"에서도 자바 웹 개발에서 이 앤트를 어떻게 유용하게 쓸 지 보여줄 것이라는군요.
서블릿에서 JSP의 편리한 setProperty를 쓸 수는 없을까?
HTML 폼에서 매개변수값을 받아올 때 빈만 잘 설계하면
오늘 톰켓이 바꿔주는 JSP의 서블릿 코드를 보니 다음과 같은 부분이 있더군요.
그건 그렇고, 과연 서블릿에서는 어떻게 써야할지. 톰켓을 쓴다면 따로 라이브러리를 설치할 필요는 없지만, 기본적으로 이 패키지는 톰켓 라이브러리중 jasper-runtime.jar에 들어있으므로 다른 컨테이너에서 쓸 때에도 절적히 적용할 수 있을 것입니다. (혹은 그 컨테이너가 바꿔주는 JSP의 서블릿 코드를 통해 알아내도 되지요.)
그리고 나서 서블릿에서 임포트를 하거나 완전수식명으로 정적 메소드인 introspect에 빈(텅 빈이 아니고 Bean) 오브젝트와 요청 오브젝트를 넘겨주면 폼 필드 이름과 빈 필드 이름을 맞춰나가며 세터(setter) 호출 끝!
하지만... 이런 코드는 솔직히 이식성이 떨어지네요. 따라서 앞으로 서블릿이나 JSP API에서 적절한 유틸리티정도로 추가해주었으면...하는 바람이 생깁니다.
EJB 2.1-XML기반 메시징으로의 길
제가 쓰려고 했으나 너무도 고맙게도 EJB 스펙 리더인 몬손하펠(Monson-Haefel)씨가 서버사이드닷컴에 잘~ 써주셨군요. 게임 프로파일(Game Profile)의 세계
관련 자료를 모으느라 이리저리 돌아다니다 보니 gamejug.org라는 아주 좋은 자바 게임 관련 사이트를 발견했습니다. 링크도 좋고 자료 정리도 풍부하고, 자바 게임에 대한 것은 여기서부터 시작해도 충분해 보입니다.
Request Time이라는 용어가 뜨기 시작했다
JSTL 1.0 스펙 문서를 보면 rt라고 줄여서 나오는데, 바로 이것이 요청시(request time)의 준말입니다. 이 말은 JSTL에서는 EL(Expression Language)와 대별해서 쓰는데,
기본적으로 웹 애플리케이션에서 다루는 정보(속성)는 항상 요청시에 동적으로 정해진다...라는 것이 이 개념의 요체입니다. 대표적인 것이 요청 매개변수로서, 어떤 값이 들어올 지는 해당 요청을 던지는 사용자(혹은 브라우저)만이 알지요. 뿐만 아니라 이러한 요청 정보와 관련된 값을 담는 변수라면 어떠한 JSP scope이라도(page건 session이건 심지어 application)이건 간에 사실상 요청시에 긴밀하게 상호작용을 하게 되므로 역시 실행시에 값을 평가해서 로직을 쫓아간다고 생각할 수 있죠.
JSP 2.0 스펙 문서에도 다음과 같은 용법으로 쓰입니다.
"에필로그를 써야지..."하며 생각하고 있던 차, 문득 제 자신을 되돌아 보았습니다. 독립 개발연구강연저술자라는 참으로 엽기적인 직업명으로 자신을 소개해야 하는 (간단히 해서 프리랜서, 혹은 알바라고 하면 될 것을) 제 자신이죠. 그래도 마냥 연구실에 처박혀 학술지만 보기도 싫고, 책만 읽고 책만 쓰기도 싫고, 강의만 하면 현실 감각이 떨어지고... 해서 매년 절반정도(하다못해 1사분기라도) 개발 프로젝트에 참여하고 싶은 마음입니다. 그래서 지금은 박박 구르며 아침 6시 기상 7시 출근 8시 반 퇴근 10시 귀가를 하고 있죠.
하지만 실제 현업에 계시는 분들을 만나뵙고 함께 호흡할 수 있어서 무척 좋습니다. 무엇보다도 저보다 전산 경력이 월등이 많으신대도 불구하고 열심히 강의와 충고를 들어주시며 제 의견을 깊이 받아들여주시는 것에 대해서는요. 그분들의 자바에 대한 열정, 아니 앞으로의 개발에서의 유지보수와 효율, 그리고 더 나은 애플리케이션 개발을 향한 애정을 느끼고 있노라면 정말 저도 열심히 연구해서 그분들에게 하나라도 더 좋은 것을 알려드리고자 자기 전에도 책을 손에서 놓을 수가 없습니다.
1년에 저술은 한 권 정도(앞으로 자바 기술서적은 안쓸거여요. T_T), 번역은 전에 맡았던 것들의 개정판이나 그간 안해봤던 일본 자바책 정도, 책 공동 집필 프로젝트의 코디네이터 한두 번 정도, 그리고 여기 자바 헤드라인에 (부)정기적으로 소식 전하고, 40이 되고, 50이 되고, 60이 되도 할 수 있을 거라는 꿈을 꾸다보면 수원과 서울을 잇는 고속도로를 질주하는 버스에서 잠에 들기 일쑤입니다.
무료 공개 UML 도구 ArgoUML
공식 사이트는 http://argouml.tigris.org/라네요. 저처럼 돈없는 UML그리고 싶은 사람에게는 참으로 고마운 존재가 아닌지... 실제로 돌려보니 간단하고도 쓸만하기도 하더군요. 클래스도와 유즈 케이스도도 한번 그려봤습니다.
Launch ArgoUML 0.10 using Java Web Start를 누르면 자바 웹 스타트로 바로 뜨기 때문에(J2SE 1.4 SDK 혹은 RE 필수) 따로 다운로드-설치 과정 필요없이 편하게 쓸 수 있습니다.
Date 클래스에 대한 기구한 사연
게시판 과제를 학생들에게 내었더니 SQL의 date타입을 자바에서 뭘로 처리해야 하는지를 많이 궁금해 하시더군요. 문자열로도 많이 처리하지만 원칙적으로 대응하는 것은 java.sql.Date입니다. 그런데 이 클래스(그리고 부모클래스인 java.util.Date)에는 다음과 같은 사연이 있습니다.
Prior to JDK 1.1, the class Date had two additional functions. It allowed the interpretation of dates as year, month, day, hour, minute, and second values. It also allowed the formatting and parsing of date strings. Unfortunately, the API for these functions was not amenable to internationalization. As of JDK 1.1, the Calendar class should be used to convert between dates and time fields and the DateFormat class should be used to format and parse date strings. The corresponding methods in Date are deprecated. - java.util.Date 클래스의 API문서에서 발췌.
무슨 뜻인고 하니, JDK 1.1 이전에는 Date 클래스로 연, 월, 일, 시, 분, 초, 날짜를 처리하고 문자열을 날짜로 주고받는 것도 했는데 이 Date 클래스가 국제화 처리를 위해 수정하기가 힘들어 JDK 1.1부터 Calendar가 날짜 관리, DateFormat이 문자열-날짜 처리를 하는 식으로 이원화되었다는 것입니다. 따라서 Calendar, DateFormat으로 이관된 메소드에 해당하는 Date 메소드는 비추천으로 찍혔습니다.
굳이 국제화에 신경 쓸 필요가 없다면 Date를 그대로 쓰셔도 무방하지만 세계화의 시대에 살고 있는 현대인이라면 Calendar로 쓰시기 바랍니다. 또 모르죠! 여러분이 짠 프로그램이 외국의 대학으로 수출될지. ^^ Date에서 Calendar를 얻어오는 방법은 의외로 쉬습니다.
Calendar writeDate = Calendar.getInstance(); writeDate.setTime(rs.getDate()); // 이때 rs는 ResultSetCalendar에는 날짜 계산(더하기 빼기)을 위한 편리한 메소드도 구비되어 있으니 자세한 것은 API 문서를 참고하시기 바랍니다.
무엇이 널일까요?
br[i]과 같이 배열의 원소를 접근하는 곳에서 NullPointerException이 나면 다음과 같은 두 가지 가능성이 있음을 생각하시기 바랍니다. 첫 번째는 br의 i번째 원소에 인스턴스가 할당되어 있지 않은 경우(원소가 null인 경우), 두 번째는 br 배열 자체가 공간 할당이 되어 있지 않은 경우(배열이 null인 경우)가 있습니다. 이점 유념하셔서 디버깅시에 고려하시기 바랍니다.
MySQL과 톰켓의 JNDI DataSource적 연동의 글 갱신
제가 2001년 12월 11일짜로 쓴 스타벅스 글(2001-12-10~2001-12-16 소식)에서
카탈리나와 MySQL과의 DataSource-JDBC2.0 표준 확장(standard extension) 방식+JNDI 자원 획득술위와 같은 이야기를 듣고 이것을 며칠 전 그대로 적용하려고 했더니 잘 안되더군요. 그래서 왜 그런가 봤더니 근본적이 이유는 다음과 같았습니다.
이유인 즉, org.gjt.mm.mysql.MysqlDataSourceFactory, org.gjt.mm.mysql.MysqlDataSource등의 JDBC 2.0 확장 구현 클래스들의 패키지가 org.gjt.mm.mysql에서 org.gjt.mm.jdbc2.optional로 더욱 세분화되어 있었습니다.
그런데 MysqlDataSource의 소스코드를 보니 그냥 써가지고는 커넥션 풀링이 일어나지 않더군요. 그렇다면 이 난관을 어떻게 해져 나가야 하는가? 대답은 간단하게도 org.gjt.mm.mysql.jdbc2.optional.MysqlConnectionPoolDataSource 클래스를 쓰면 됩니다. (참고로 MysqlConnectionPoolDataSource는 MysqlDataSource를 확장하고 ConnectionPoolDataSource를 구현했더군요) 그래서 다음과 같이 위의 원문을 수정합니다.
먼저 server.xml쪽은
다음은 web.xml에서factory org.gjt.mm.mysql.jdbc2.optional.MysqlDataSourceFactory user 사용자명... password 암호... serverName localhost databaseName angels port 3306
위와 같이 해주면 MySQL이 제공하는 커넥션 풀링과 더불어 쾌적한 DB 연결 작업을 할 수 있습니다.jdbc/test org.gjt.mm.mysql.MysqlConnectionPoolDataSource
자바 공식 사이트 개편에 대해
썩 나쁘지는 않는데 새로운 기술을 일목요연하게 보여주는 페이지가 꽁꽁 숨어버렸군요. 대신 "Recent Release"라는 이름을 가진 페이지가 새롭게 생겼습니다. 링크는 바로 여기 입니다.
JMX 책 소개
이미 오라일리에서도 『Java Management Extensions』이라는 책이 이미 출간되었듯이 매닝에서도 『JMX In Action』 이라는 책을 출간하여 서버사이드닷컴(serverside.com)에서 일반인의 검토 참여를 유도하고자 공개하고 있습니다. 톰켓 4.1을 비롯해서 앞으로의 웹 애플리케이션 서버가 거의 채택할(J2EE1.4에서는 기본) JMX 기술에 대한 논의가 벌써부터 뜨거운 느낌입니다.
J2EE Application Deployment and Management의 Spec과 RI 등장!
각각 JSR-88과 77에서 연구되었던 기술이 http://java.sun.com/j2ee/tools/deployment/와 http://java.sun.com/j2ee/tools/management/로 정식 공개되어 스펙 관련 문서 참조 구현이 나왔습니다. 그동안 J2EE 애플리케이션의 배치와 관리 기술에 표준이 없어 WAS별로 다르게(proprietary) 돌아가던 것을 통합하는 데 어떤 기여를 할지 기대됩니다. 특히 참조 구현체는 포르테 커뮤니티 에디션과의 결합도 지원하므로 (무료) 개발시에 도움이 될 것입니다.
CLDC 1.0 HotSpot - 2.5G 이동통신을 위한 자바 플랫폼
아주 우연치 않게 CLDC 1.0 문서 사이트에서 위와 같은 PDF 팜플렛을 보게 되었습니다. 아직 CLDC 1.1의 스펙과 단말기 둘 다 완전하게 발표되지 않은 상황이지만 차세대와 현세대의 간격을 메우기 위한 포석이라고 보여집니다. 특히 이동통신 기술의 발전과 더불어 대역폭이 증가하면서 더욱 더 강력한 자바 애플리케이션을 요구하는 시장의 요구에 부응하는 길이기도 하겠지요. 기본적으로 J2SE의 핫스팟 철학을 그대로 계승하면서 CLDC의 현실적 제약을 극복하는 데에 초점이 맞춰져 있습니다. 과연 플랫폼 구현자들이 강력한 암(ARM) CPU와 충분한 메모리를 통해 CLDC 1.0 핫스팟 머신을 만들어낼지 기대가 됩니다.
Java Pet Store Demo 1.3.1 - 팻스토어가 웹 서비스로 다시 태어난다?
이 데모는 http://developer.java.sun.com/developer/releases/petstore/index.html에 가면 받을 수 있습니다. 썬이 탑 페이지에 대대적으로 홍보까지 하는데 과연 어떠한 바람이 불지... 저도 이번 달 20일에 하는 자바 웹 서비스 공개 세미나에서 계획했던 예제대신 이것을 보여드려야 할지도 모르겠습니다.
Java 3D 1.3 공개
http://java.sun.com/products/java-media/3D/에서 스펙과 구현체를 받으실 수 있습니다. J2SDK 1.4와도 잘 돌아가고, 디렉트X 8.0이상에서 아주 좋습니다. (저는 사정상 OpenGL판을 쓰지만요.) 이제부터 『생생한 게임 개발에 꼭 필요한 기본 물리』의 예제(Win32-C계열로 되어 있음)를 자바로 포팅하는 프로젝트인 "애플(Apple-이 코드명의 유래는 프로젝트 공식 사이트에 있음)"을 정식으로 시작할 수 있게 되었습니다. 더불어 JSR-189로 Java 3D 1.4 연구가 시작되었습니다. 여러분들의 많은 관심 바랍니다.
자바 웹 애플리케이션의 얼굴-JSF(JavaServer Faces) 드디어 모습을 드러내다!
하지만 안타깝게도 JSR-127 EG(Expert Group)과 JCP 회원에 한해서입니다. 현재 조직 내 검토(Community Review) 1차 초안으로서 CR치고는 비교적 상세한 스펙을 자랑합니다. 다음 세대의 자바 웹 개발의 비전을 엿볼 수 있는 몇 가지 용어를 살짝 소개해드리죠.
- 일선 개발자(corporate developer): 절차적 코드와 비즈니스 로직을 짜는 데에 능숙한 사람(객체지향에는 익숙할 필요가 없음). 개발 툴에 많이 의존한다.
- 시스템 프로그래머(system programmer): 재사용을 위한 추상화와 설계를 포함한 객체지향 기초를 이해하고 있는 사람. 텍스트 에디터로 서버에서 직접 작업한다.
- 페이지 작성자(page author): 웹 애플리케이션의 사용자 인터페이스를 만드는 일을 주로 하는 사람. HTML이나 자바스크립트와 같이 클라이언트(브라우저)가 받아들이는 마크업 언어(태그 코드)뿐만 아니라 (JSP같은) 동적 컨텐츠를 만드는 렌더링 기술에도 빠삭하다. 업계에서 주로 "삽질"한다고 비하하는 분위기도 있지만 결코 그렇지 않다(고 특히 이아스는 생각함). 그들의 노고로 오늘날 한국 웹 세계는 건설되었으며 당당히 한국 IT 발전의 밑거름 역할을 한 산업 역군이 아니라 할 수 없다. (누가 뭐라고 그래도 자부심을 갖자. 저도 삽질 하거든요. ^^)
- 컴포넌트 작성자(component writer): 재활용할 사용자 인터페이스 오브젝트의 라이브러리를 만드는 사람. 어찌보면 신종 직업으로서 솔루션 제작의 성향이 짙다. 이 역할에 대해서는 앞으로 상당한 논의(혹은 논쟁?)가 있을 지도...
- 애플리케이션 개발자(application developer): 사용자 인터페이스와 직접적인 관련이 없는 웹 애플리케이션의 서버측 기능을 구현하는 사람. JDBC, EJB등을 주로 다룬다.
- 툴 제공자(tool provider): JSF를 편하게 쓸 수 있도록 툴을 만들어 파는(혹은 그냥 뿌리는) 사람. 일선 개발자에게는 특히 없어서는 안될 존재다.
- JSF 구현자(JSF implementor): 말 그대로 JSF 스펙을 구현할 사람. 이 모든 시나리오의 총 감독(이자 심부름꾼)이다.
"역할이 개인을 구분하는 것은 아니다."무슨 말인지 다소 추상적인데 쉽게 풀어 쓴다면 "한 사람이 꼭 한 역할만을 맡는 것은 아니다."라는 이야기입니다. 이아스라는 개발자가 프로젝트를 뛴다면 오전에는 페이지 작성자가 오후에는 애플리케이션 작성자가 될 수 있습니다. 그렇다면 무엇하러 저렇게 이상적으로 역할을 나누어 놓았을까요? 과연 역할과 인력의 일대일 대응으로 완벽한 분업화가 이루어질 수 있을까요?
그것은 아니라고 봅니다. 이 시점에서, 그리고 앞으로의 시점에서 중요한 것은, 자신에게 맡겨진 즉 책임을 지는 임무에 어떠한 역할을 적용하고 그 역할을 수행할 때 어떠한 기술과 상황 판단력이 필요한지를 잘 아는 것이 아닐까요? 히딩크 감독의 "모든 포지션 다 가능하기" 전략은 비단 한국 축구의 4강 신화에만 필요한 것은 아니지 않을까... 오히려 지금까지 애매한 책임전가식의 "역할 분담"이 새로운 국면을 맞이하는 데에 위의 개념들이 도움이 되기를 바랍니다.
아! 참고로 JSF은 서블릿 2.3(고로 JSP 1.2)에 기반하고 있습니다. JSTL은 한단계 더 낮은 서블릿 2.2(JSP 1.1)까지 포용하고 있죠. 물론 JSF와 JSTL은 올 하반기에 출시예정인 J2EE 1.4에 기본 사양으로 들어갈 것이지만 이렇게 새로운 시장만을 염두에 둔 것이 아니라, 현재 많이 쓰이고 있는 자바 웹 환경으로부터의 마이그레이션(사이트 개편, 향상 등의 프로젝트)이라는 기존 시스템으로부터 파생되는 수요도 감안하고 있는 "두 마리 토끼를 다 잡아보겠다"는 야심찬 첫걸음입니다. 과연 JSF와 JSTL(그리고 포틀릿(Portlet)까지)이 2002년 여름이후의 웹 개발을 바꾸어 놓을지, 의외로 그 시간은 얼마 걸리지 않을 수도 있습니다.
Ant 1.5 발표
http://jakarta.apache.org/ant/index.html가 공식 사이트입니다. 곧 공식 개시를 발표할 "퍼펙트 JSP 2판 제작 프로젝트-코드 네임 인빈서블"에서도 자바 웹 개발에서 이 앤트를 어떻게 유용하게 쓸 지 보여줄 것이라는군요.
서블릿에서 JSP의 편리한 setProperty를 쓸 수는 없을까?
HTML 폼에서 매개변수값을 받아올 때 빈만 잘 설계하면
오늘 톰켓이 바꿔주는 JSP의 서블릿 코드를 보니 다음과 같은 부분이 있더군요.
JspRuntimeLibrary.introspect(obj, request);대강 이런 명령이
그건 그렇고, 과연 서블릿에서는 어떻게 써야할지. 톰켓을 쓴다면 따로 라이브러리를 설치할 필요는 없지만, 기본적으로 이 패키지는 톰켓 라이브러리중 jasper-runtime.jar에 들어있으므로 다른 컨테이너에서 쓸 때에도 절적히 적용할 수 있을 것입니다. (혹은 그 컨테이너가 바꿔주는 JSP의 서블릿 코드를 통해 알아내도 되지요.)
그리고 나서 서블릿에서 임포트를 하거나 완전수식명으로 정적 메소드인 introspect에 빈(텅 빈이 아니고 Bean) 오브젝트와 요청 오브젝트를 넘겨주면 폼 필드 이름과 빈 필드 이름을 맞춰나가며 세터(setter) 호출 끝!
하지만... 이런 코드는 솔직히 이식성이 떨어지네요. 따라서 앞으로 서블릿이나 JSP API에서 적절한 유틸리티정도로 추가해주었으면...하는 바람이 생깁니다.
EJB 2.1-XML기반 메시징으로의 길
제가 쓰려고 했으나 너무도 고맙게도 EJB 스펙 리더인 몬손하펠(Monson-Haefel)씨가 서버사이드닷컴에 잘~ 써주셨군요. 게임 프로파일(Game Profile)의 세계
관련 자료를 모으느라 이리저리 돌아다니다 보니 gamejug.org라는 아주 좋은 자바 게임 관련 사이트를 발견했습니다. 링크도 좋고 자료 정리도 풍부하고, 자바 게임에 대한 것은 여기서부터 시작해도 충분해 보입니다.
Request Time이라는 용어가 뜨기 시작했다
JSTL 1.0 스펙 문서를 보면 rt라고 줄여서 나오는데, 바로 이것이 요청시(request time)의 준말입니다. 이 말은 JSTL에서는 EL(Expression Language)와 대별해서 쓰는데,
- (스펙 문서) 19쪽 - JSTL은 애플리케이션을 쉽게 접근하고 다루게 해준다, 스크립틀릿이나 요청시 표현값(RT Expression Value)없이도.
- 20쪽 - JSTL은 EL과 RT EV를 각각 지원한다. (고로 EL과 RT-EV는 동등한 개념이다.)
기본적으로 웹 애플리케이션에서 다루는 정보(속성)는 항상 요청시에 동적으로 정해진다...라는 것이 이 개념의 요체입니다. 대표적인 것이 요청 매개변수로서, 어떤 값이 들어올 지는 해당 요청을 던지는 사용자(혹은 브라우저)만이 알지요. 뿐만 아니라 이러한 요청 정보와 관련된 값을 담는 변수라면 어떠한 JSP scope이라도(page건 session이건 심지어 application)이건 간에 사실상 요청시에 긴밀하게 상호작용을 하게 되므로 역시 실행시에 값을 평가해서 로직을 쫓아간다고 생각할 수 있죠.
JSP 2.0 스펙 문서에도 다음과 같은 용법으로 쓰입니다.
- (스펙 문서) 81쪽 - 요청시 속성 값(바로 RT EV)은 지시자(directive, <%@ ~ %> 형식의 JSP요소)에 쓸 수 없다. 지시자의 모든 속성은 번역시(translation-time, 컨테이너가 JSP을 서블릿으로 번역하는 시점, 이하 TT)에 결정할 수 있어야 한다.
- 82쪽 - 지시자와 같은 XML방식을 취하고 있는 액션(action)의 경우에는 RT EV를 속성으로 허용한다. (
- 번역시(Translation Time) - JSP 번역시 - JSP 컴파일시
- 요청시(Request Time) - JSP 요청시 - JSP 실행시
"에필로그를 써야지..."하며 생각하고 있던 차, 문득 제 자신을 되돌아 보았습니다. 독립 개발연구강연저술자라는 참으로 엽기적인 직업명으로 자신을 소개해야 하는 (간단히 해서 프리랜서, 혹은 알바라고 하면 될 것을) 제 자신이죠. 그래도 마냥 연구실에 처박혀 학술지만 보기도 싫고, 책만 읽고 책만 쓰기도 싫고, 강의만 하면 현실 감각이 떨어지고... 해서 매년 절반정도(하다못해 1사분기라도) 개발 프로젝트에 참여하고 싶은 마음입니다. 그래서 지금은 박박 구르며 아침 6시 기상 7시 출근 8시 반 퇴근 10시 귀가를 하고 있죠.
하지만 실제 현업에 계시는 분들을 만나뵙고 함께 호흡할 수 있어서 무척 좋습니다. 무엇보다도 저보다 전산 경력이 월등이 많으신대도 불구하고 열심히 강의와 충고를 들어주시며 제 의견을 깊이 받아들여주시는 것에 대해서는요. 그분들의 자바에 대한 열정, 아니 앞으로의 개발에서의 유지보수와 효율, 그리고 더 나은 애플리케이션 개발을 향한 애정을 느끼고 있노라면 정말 저도 열심히 연구해서 그분들에게 하나라도 더 좋은 것을 알려드리고자 자기 전에도 책을 손에서 놓을 수가 없습니다.
1년에 저술은 한 권 정도(앞으로 자바 기술서적은 안쓸거여요. T_T), 번역은 전에 맡았던 것들의 개정판이나 그간 안해봤던 일본 자바책 정도, 책 공동 집필 프로젝트의 코디네이터 한두 번 정도, 그리고 여기 자바 헤드라인에 (부)정기적으로 소식 전하고, 40이 되고, 50이 되고, 60이 되도 할 수 있을 거라는 꿈을 꾸다보면 수원과 서울을 잇는 고속도로를 질주하는 버스에서 잠에 들기 일쑤입니다.
TAG :
이전 글 : Programming C# - 2부
다음 글 : 특허 전쟁: 뒤통수를 때린 W3C
최신 콘텐츠