한빛출판네트워크

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

JSP 2.0이 J2SE 1.4를 요구하는 이유

최근 톰켓 개발자 메일 목록을 통해 톰켓 5의 J2SE 요구 버전에 대한 논쟁에 대해 JSP 2.0 규격의 선임 연구자인 마크 로스(Mark Roth)씨가 입장을 밝혔습니다. 아래는 그 전문입니다.

It has been brought to my attention that some members of the Tomcat community have expressed a desire to see a requirement lower than J2SE 1.4 in JSP 2.0.

First, let me reassure you that the JSP 2.0 specification is not final. Actually, we are in Proposed Final Draft phase, and we are explicitly soliciting feedback! Early feedback is always much appreciated. As per the cover of the specification, the appropriate forum for feedback is jsp-spec-comments@eng.sun.com.

Regarding the J2SE 1.4 requirement, the expert group discussed the topic in early August (as issue "[OTH-17] J2SE Version Requirement") and there was concensus from the different experts, but the EG is open to additional comments. You can send mail directly to jsp-spec-comments@eng.sun.com, or, maybe better in this case, talk directly to the Apache representatives to the Expert Group: Ricardo Rocha (ricardo@apache.org) and Geir Magnusson Jr. (geirm@apache.org). In general the more feedback the rep has from his community the better for the Expert Group.

For what it"s worth, the only technical reasons we require J2SE 1.4 are:

1. We require support for JSR-45 (Debugging Support for Other Languages)
2. We declare support for Unicode 3.0 in our I18N chapter.


Actually, JSR-45 is quite important for the platform as a whole. For example, it was recently pointed out to me that there"s a bug report against Tomcat 5 because we didn"t re-implement the pseudo-debug comments that Jasper 1 used to create, and that some tools relied on. Standard debugging annotations is an important enabler, and it would be a shame to have to wait even longer for it.

From my perspective, the most significant reason to require J2SE 1.4 is that it would be best if people can write portable tag handlers that utilize J2SE 1.4 libraries, and be able to use them in any JSP 2.0 application. Do we really want to stagnate on J2SE 1.2 APIs forever?

I"ve compiled a list of new features in J2SE 1.3 and J2SE 1.4 that I believe would be of use to page authors and tag library developers that would decide to use JSP 2.0. It would be awesome, IMHO, if page authors and tag library developers could rely on these features being present in any JSP 2.0 compliant container. This list was also discussed in the Expert Group.

J2SE 1.3 adds (among other features):

* Built-in JNDI
* RMI/IIOP
* CORBA ORB
* PNG support (for image taglibs)
* Various Security enhancements
* Improved socket support
* HTTP 1.1 client-side support
* DynamicProxy
* Serialization enhancements
* Collections enhancements
* BigDecimal and BigInteger enhancements
* StrictMath
* Timer API
* Delete-on-close mode for opening zip and jar files
* JPDA tool support


J2SE 1.4 adds (among other features):

* XML Processing
* New I/O APIs
* Security: Java Cryptography integrated
* Security: GSS-API, Certification Path API
* Pluggable Image I/O framework
* Print Service API
* Standard Logging APIs
* Long-term Persistence of JavaBeans
* JDBC 3.0
* Assertions
* Preferences API
* Chained Exception Facility
* IPv6 Networking Support
* JNDI enhancements
* CORBA ORB with POA
* *** JSR-45 (Debugging Support for Other Languages) ***
* *** Unicode 3.0 ***
* Currency class
* Collections Framework enhancements
* Built-in support for Regular Expressions

정리하자면, JSP 2.0의 타 언어 디버깅 지원 기능이 J2SE 1.4를 요구하기 때문이라는 것입니다. 의외로 현재 서블릿 규격 2.4와 JSP 2.0 규격은 J2SE 1.4의 NIO나 기타 다른 기능의 언급을 하지 않고 있습니다.

톰켓 서브프로젝트화

톰켓이 점차 거대해지고 있는 가운데, 제가 한가지 아이디어를 떠올렸습니다. 바로 톰켓의 분할이죠.

카탈리나 2.4-서블릿 2.4-JDK 1.2
제스퍼 2.0-JSP 2.0-JDK 1.4
커넥터-코요테, JK2
첨가물(add-on)-JDBC 표준 확장 DB 연결 풀링, NIO 가속기, 관리자 애플리케이션 등

그림으로 보는 구조는 아래와 같습니다.

JSP 엔진 + 첨가물

-----------------

서블릿 컨테이너

자세한 내용은 이 사이트에 있습니다. 그리고 여기에 대해서 톰켓 내부에서는 다음과 같은 의견들이 있습니다.

[잠깐 용어: 자바 2 클래식=J2SE 1.2~1.3, 자바 2 모던=J2SE 1.4~]

• JSP 2.0의 자바 2 모던 요구는 확정적이 아니다.(현재 규격은 최종권고안 상태에 있습니다.)
• 기능성을 위해 이식성을 희생할 수 없다. (여기에 대한 명언이 있습니다. "기능성을 더 생각하고 이식성을 덜 생각한다면, C#으로 짜서 윈도우에서 돌리겠다." -Costin Manolache)
• JSR-152 (JSP 2.0)의 EG로서 아파치를 통해 자바 2 클래식을 수용하도록 압력을 넣어야 한다.
• 만약 톰켓 5에 JSP 2.0을 탑재할 수 없다면, 벨로시티나 코쿤과 같은 다른 템플릿 엔진을 올리는 대안도 강구해봐야 한다.
• 자바 2 클래식에서 톰켓 5를 돌아가게 하기 위해 자바 2 모던을 희생해서도 안된다.
• 썬의 자바 2 모던 VM만으로는 부족하다. 타 업체의 자바 2 모던 VM이 어느 정도 나올 때까지는 현실적인 타협이 있어야 한다.

이런 정황으로 보아서, 아파치 측에서는 JSR-152에 J2SE 요구수준에 대한 재협상을 요청할 것으로 보입니다. 썬이 JSP 2.0으로 새로운 JSP 제작 방식을 제안하고자 하는 가운데, 아파치로서는 자바의 최대 장점인 이식성을 보장할 수 있어야 한다는 의견이 지배적입니다.

제가 톰켓의 동향을 예의주시하는 데에는 다음과 같은 까닭이 있습니다. 자바 웹 기술의 원천이 되어왔던 서블릿, 그리고 그 간판격인 JSP의 모범이 되어왔던 것이 톰켓입니다. J2EE 1.4를 구현할 많은 업체들이 바로 이 톰켓을 참고할 것입니다. 현재 톰켓을 통해 나온 의견들은 바로 이 업체들과 업체 고객들의 의견과 진배없습니다. 새로운 것, 강력한 것도 좋지만, 자바를 도대체 왜 써왔는가, 그것은 바로 실제적인 이식성에 있어왔다는 것입니다. 자바 1에서 자바 2로 올라오는 데에는 오히려 큰 진입 장벽이 없었지만, 자바 2 클래식에서 자바 2 모던으로는 상황이 또 다릅니다. 1998년~1999년 당시의 자바는 경쟁자도 없이 자유로웠고 모든 면에서 여유로왔으며 관대했지만, 2001년~2002년의 자바는 닷넷이라는 강력한 경쟁자와 더불어 모든 것이 힘든 상황입니다. 자바 3로 가는 길, 그 가운데 있는 자바 2 모던과, JSP 2 스타일로 가는 길, 그 가운데 있는 JSP 2.0은 이제 한 배를 탈 것인지, 아니면 자신의 이름을 세상에 날리게 해주었던 "이식성"에 스스로 발목이 잡힐지, 선택은 다른 누구도 아닌 자바인들에게 달려있습니다.

여러분들의 생각은 어떻습니까? 아파치쪽에 의견 개진하고 싶으시다면 tomcat-dev-subscribe@jakarta.apache.org로 가입하셔서 http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/을 보시기 바랍니다. JSR-152쪽으로는 jsr-152-comments@jcp.org?subject=JSR%20152%20Comments로 하시면 되겠습니다.

J2EE는 너무 복잡하다?

이 내용은 여기에 원문이 있습니다. 지나친 규격의 복잡도가 문제라는 것인데, 독자들의 의견도 많습니다. 대체로 J2EE (1.4)의 방대함에 대해서는 지적하고 있습니다만 과연 이런 정황을 어떻게 해결할지는 모르겠습니다.

사라진 JSR

여기를 보시면 알겠지만 자바 데몬이라는 기술이 있었는데 내부 검토단계에서 철회되었습니다. 내부 검토 투표 결과를 일반인에게는 공개하지 않았지만 아주 특이한 이유 때문에 철회되었더군요. 지금은 JMX와 같은 기술로 대체되고 있지만 자바 데몬! 자바 역사의 한 시대를 풍미했던 기술이자 이제는 그 화석만 남은 기술이기도 합니다.

톰켓의 web.xml 광역 정의와 지역 정의

다음과 같은 경우가 있다고 가정해 봅시다. 현재 /URL 패턴을 처리하는 디폴트 서블릿을 톰켓이 제공하는 것이 아닌 나름대로의 것으로 바꾸어 모든 컨텍스트에 적용하고 싶다면 어떻게 해야 좋을까요?

톰켓 4.1부터는 이렇게 모든 컨텍스트에 적용하고 싶은 라이브러리를 shared에 넣습니다. 그 나름대로의 디폴트 서블릿을 shared/classes(클래스 파일)나 shared/lib(자 파일)에 두고, conf/web.xml을 고치면 광역 설정(global setting)이 되어 도든 컨텍스트에 적용됩니다.

default

iasandcb.DefaultServlet

그런데, 여기서 주의깊게 볼만한 점은 shared/classes-shared/lib-각 컨텍스트/WEB-INF/classes-각 컨텍스트/WEB-INF/lib 순으로 클래스를 불러들인다는 것이죠. 덧붙여서 conf/web.xml-각 컨텍스트/WEB-INF/web.xml 순으로 적용되며, 후자의 web.xml은 전자의 정의를 번복할 수 있습니다. 예를 들어 conf/web.xml에서 다음과 같이 한 것을

index.html
index.htm
index.jsp

iasandcb 컨텍스트의 WEB-INF/web.xml에서 아래와 같이 재정의 하면,

index.html
index.htm

iasandcb 컨텍스트에서 http://localhost:8080/iasandcb/와 같이 부를 경우 index.jsp는 자동호출되지 않습니다. 톰켓 5도 이런 원리를 따르고 있습니다.

덧붙이는 말

이번 주 소식은 톰켓쪽으로 치우친 것 같습니다. 최근 더 많은 자바인들이 여러 방면에서 적극적인 활동을 보이고 있어 가슴이 뿌듯합니다. 자바계의 모든 분들께 성공을 빕니다.