한빛출판네트워크

저자: 이아스님(http://www.iasandcb.pe.kr)

드디어 오라일리에서 『Java Swing』 개정판이 출간되었습니다. 이번 개정판에서는 단순한 스윙 컴포넌트 설명을 나열하는 것이 아니라 좀더 실용적인 예제까지 제공한다고 하는군요. 물론 JDK 1.4도 다루고 있습니다. 그리고 JAXP를 지탱하는 구분 분석기와 변환기의 최신판인 저시스 2.2.0 + 잴런 2.4.0이 나왔습니다.

JAXP 1.1에서 1.2로 바뀐 것은 스키마 검증 뿐! API적인 구조변경은 없었다!

"JAXP 1.3에서 그 이상으로 바뀐다면, JDK 1.4의 안에 들어있는 (갱신 불가능한) JAXP 1.1은 어떻게 될 것인가?"에 대한 의문에 대해 상상할 수 있는 시나리오는 다음과 같습니다.

• JDK 부분 업데이트를 이용한다.
• 따로 패치를 내놓는다.

과연, 어떻게 될까요? ^^

JDK 1.4에서 java.util.Locale 클래스의 새로운 생성자

new Locale(언어 코드)이 있더군요. 이제 언어 코드만 가지고도 로케일을 설정할 수 있게 되었습니다(참고로, 이전에는 국가 코드까지 꼭 있어야 했죠).

JSP 2.0의 page 지시자의 pageEncoding 속성에 대한 JSP 설정 방식에 대한 얼개 분석

JSP 1.2부터 page 지시자에는 pageEncoding이라는 속성이 포함되었지만, 이 속성이 contentType에서의 인코딩 설정(예: text/html;charset=euc-kr)과 개념상 유사하면서 상호 관계와 적용에 대한 정리가 되지 않았으나, JSP 2.0에서는 pageEncoding은 JSP 페이지에 대한 인코딩, contentType은 JSP 페이지가 생성하는 응답의 인코딩이라는 기본 개념아래, pageEncoding 설정이 contentType을 상회하는 얼개를 규정하였습니다.

예를 들어 <@page pageEncoding="euc-kr">이라고 하는 경우 이 JSP 페이지는 자동적으로 응답 인코딩까지 euc-kr이 됩니다.

특히 JSP 2.0에서 새로이 등장한 JSP 설정(배치 설명서에 JSP에 관련한 설정을 함) 기능을 통해 JSP별로 URL 대응으로 페이지 인코딩을 설정할 수 있습니다. 현재 JSP 2.0의 참조 구현체인 톰켓 5에서는 다음과 같은 web.xml을 예제로 보여주고 있습니다.

 <-- 서블릿 규격 2.4부터는 web.xml에 대해 DTD대신 스키마를 씀
...

 <-- JSP 설정 시작


http://jakarta.apache.org/tomcat/debug-taglib


/WEB-INF/jsp/debug-taglib.tld





http://jakarta.apache.org/tomcat/examples-taglib


/WEB-INF/jsp/example-taglib.tld





http://jakarta.apache.org/tomcat/jsp2-example-taglib


/WEB-INF/jsp2/jsp2-example-taglib.tld

 <-- 태그립 설정



Special property group for JSP Configuration JSP example.

JSPConfiguration
/jsp2/misc/config.jsp <-- 해당 패턴에 대해서(만) 
true
ISO-8859-1 <-- 페이지 인코딩 설정 가능 
true
/jsp2/misc/prelude.jspf
/jsp2/misc/coda.jspf

 <-- JSP 속성 설정

이러한 원리를 도입하면, 한글 JSP 페이지를 작성할 시에 <@ page contentType... >이나 <@ page pageEncoding ..>과 같은 지시자를 매번 쓸 필요 없이 *.jsp URL 패턴에 euc-kr 페이지 인코딩을 주면 해당 컨텍스트에 속한 모든 JSP 페이지에 한글 인코딩이 적용되어 무척 쾌적한 JSP 제작을 할 수 있습니다.

J2EE 1.4의 기본 사양인 JSP 2.0의 지역화적 의의를 엿볼 수 있습니다.

최근 아파치가 썬으로부터 얻어낸 TCK 관련 성과

자세한 내용은 이곳을 클릭하면 볼 수 있습니다. 먼저 비상용, 교육 목적의 TCK 사용에 대해서는 무상으로 하기로 결정하였습니다. 이미 아파치 프로젝트 자체도 이 TCK를 통과하였습니다. 정리해보면 아파치 프로젝트 산물이 TCK를 통과하는 데에는 비용이 들지 않는다는 뜻인데요.

또한 아파치는 비상용, 교육 목적에 TCK를 제공하는 대표로 활동합니다. 그렇다면 상용 TCK를 통과하기 전에, 미리 아파치가 제공하는 TCK로 시험을 해볼 수 있다는 뜻이 됩니다. 주요 XML(웹 서비스) 기술, 서블릿/JSP가 현재 해당됩니다.

JBoss가 EJB에 대한 아파치에 상응하는 역할을 요구할 지도 모릅니다. 이런 효과가 파급되면 자바 기술 전체에 대한 공개 무료 TCK가 퍼져나갈 것입니다.

더불어, 독립적으로 구현체를 만들지 않고 (이것을 독립 구현체, independent implementation라고 함), 아파치 산물과 같은 오픈 소스 TCK 통과물을 바탕으로 구현체를 만들면, 자연스럽게 아파치의 라이센스를 통해 TCK 비용없이 해당 기술 인증 구현체를 내놓을 수 있게 됩니다.

문제는 아파치 라이센스에 "코드 변경 허락" 부분에 있는데, 이 부분에 대해서는 앞으로 어떠한 방식으로 진행될지 귀추를 주목해볼만 합니다.

아파치 웹 서버에 이어 톰켓도 점차 상업적 용도(product use)가 가능한 수준으로 품질이 향상되고 있습니다. 특히 XML쪽은 아파치 산물에 의존하는 정도가 커서, 저시스, 잴런, 액시스등이 이미 상업적 용도로 널리 쓰이고 있습니다.

따라서, 이러한 기반 기술에 대한 오픈 소스 채용은 핵심에 있어 차별성을 역으로 사라지게 하는 부분이 있습니다.

즉, IBM이나 BEA와 같은 경우 이러한 기반 기술을 오픈 소스로부터 얻고, 부가적인 요소로 차별성과 사업성을 찾는다는 이야기입니다. 다만, 오픈 소스의 특성이었던 관리 부재에 대해서는 아파치에 그만큼의 지원과 감시를 하는 것도 소홀히 하지 않고 있습니다. 이런 상황을 바탕으로, 규격의 제정에서부터 구현체 제작, 그리고 (비)상업적인 판매에까지 일체의 라이센스 비용이 들지 않는 자바 기술 사업 진행의 방법이 고안된 셈이죠.

덧붙이는 말

이번 주는 최근 본 한 편지 목록(mailing list)의 명언으로 대신하겠습니다.

verba volant, scripta manent - discussions get forgetten, just code remains.
논의는 잊혀지고, 코드만 남는다. (Nicola Ken Barozzi - nicolaken@apache.org)