Hi I'm Changshin Lee, a JCP individual member. I'm also a member of JSR-179 "Location API for J2ME" EG. I've always appreciated your work, "Tomcat".
In this message, I'd like to make a proposal on resolving localization issues on SRV-JSP technology and its reference implementation. Actually I have some experience which is very similar with this situation: the uploading module in com.oreilly.servlet(COS) package by Jason Hunter. I emailed to him about COS i18n(and l10n) around 2 years ago, and unfortunately got little attention. At that time I felt very sorry because not only Korean developers but also all the non-Latin-1-based developers faced that problem. I patched COS to COSI(COS I18n) by myself since COS showed no interest in i18n. COSI had around 2 years of lifetime for claiming the i18n of COS, and finally COS adopted the idea of COSI and I happily stopped maintaining COSI for people to prefer COS for the future. ( Due to the efforts, I could become the official Korean translator of "Java Servlet Programming" from O'Reilly. You can touch the fossil of COSI on following links English - http://www.iasandcb.pe.kr/English/cosi/index.html Japanese - http://www.iasandcb.pe.kr/Japanese/cosi/index.html Korean - http://www.iasandcb.pe.kr/Korean/cosi/index.html ) The reason why I wrote here a long and boring history about my private thing is simple and clear enough. We need to achieve complete and convenient i18n and l10n, and it really takes some time. The only one thing I hope for is that the time would be as short as people get happy. I've investigated these issues on tomcat mailing list and some suggested brilliant ways to overcome the current situation. About request encoding, http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg13334.html Also about response encoding http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg26720.html and more fundamentally, http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg08912.html First, filter policy works fine for both SRV and JSP with respect to request. However, it doesn't work for JSP with respect to response. The reason is also mentioned at the link. About the changes(and possilby the improvements) of web.xml for l10n, I also wrote the following messages to JSP spec lead. The first message: I have requests about response and request configuration. Since Java Servlet Technology was born, its localization issues were discussed hard. Now we can set up response's content type and request's encoding, however, the processes need programmatic accesses. Servlet Developer must call the related methods whenever it is necessary. I know some specific web containers support some configurations for the default set-up, but I think Servlet Specification should standardize how it works through web.xml context. Probably Servlet Filtering can be a solution. But I wish that everyone can define them in "web.xml" for more convenience and avoid modifying a web container with source level such as tomcat localized patch. ----- The second message: I checked out <locale-encoding-mapping-list> element in SRV 2.4 DD (SRV 13.2 p116). I understand that the element maps a locale to an encoding, but doesn't specify the default locale(or encoding) for a given web application(context). According to JSP 2.0 PDF (Localization Issues), pageEncoding concept is introduced for more convenient localization. However, it just applies to JSP pages, not based servlet class codes. At this moment, I'd like to propose default request character encoding default response content type default response locale(or encoding) default response buffer size elements in SRV 2.4 DD. Many developers for non-Latin-1 services have long for the above settings. Moreover, nowadays many web applications are mainly provided as non-text/html pages such as WAP and XHTML. In some sites, web applications should generate a lot of contents in one page, so the current default buffer size of 8~16kb is not enough. (Heavy statistics or multimedia are such examples.) ----- Unfortunately, I had no answers for the second message. (The answer for the first one is "understanding and effort" briefly with the insufficient alternative <locale-encoding-mapping-list>.) So, I confirmed that we need something more and more. Actually the filter policy for SRV is very good, and I attached an integral version of the filter to this message. (In ias.zip, you can extract ContentFilter in ias/WEB-INF/classes directory) With ContentFilter and web.xml, you can configure all servlets' content type and response encoding and request encoding smoothly. The example Test servlet (you can invoke via http://localhost:8080/ias/servlet/Test by installing ias context) also displays correct settings for the configured web.xml. On JSP side, as you can guess, it gives a little different result. Conclusively, you can set up request encoding, but cannot do so to response encoding because of JSP's generation mechanism. In this case, JSP 2.0 spec has page-encoding feature, so we can compensate the misfeature of the filter. In spite of its meaning, the page-encoding is slightly different to response encoding of a JSP page. JSP is based on SRV, so I think it is good for JSP to follow SRV's policy. Surely we have to revise SRV and JSP's spec, but need considerably long time for inevitable processes. Therefore, finally I propose the following methods: 1. Tomcat contain ContentFilter as not a example but a default filter. That means once you install Tomcat, you can use ContentFilter without more necessary jobs for installing and deploying the filter. (Regardless of this convenience, you should modify web.xml for filter enabling and detailed configurating.) 2. JSP compile mechanism accept the filter. If ContentFilter filters /* or *.jsp, JSP compiler makes a JSP headed by the given content type and response encoding. 3. This "de facto" standard mechanism for l18n of SRV and JSP be adopted by JSR specs. I believe we have many who can make these things come true including myself. Thank all of you for bearing boredom of reading this message. I wish warmer and warmer global world with every language spoken and written. IAS Independent Java Technical Evangelist & Project Coordinator http://www.iasandcb.pe.kr
ias.zip
Description: Zip compressed data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
