The API is *not* optional. It is a required part of the servlet spec.
It works just great in Tomcat 4.1 and is not an acceptable regression in Tomcat 5. I am thus one step away from re-opening this bug (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929)
I cannot use the encoding setting on the connector as the standard handling of servlet parameters is ISO-8859-1 decoding unless setCharacterEncoding() is used to specify something else. All of our other code thus follows this standard carefully (and works across all servlet engines tested). [This includes handling multi-byte data in servlet parameters.] This does require some careful shuffling to workaround the fact that the wrong encoding was used by the servlet engine and to use the correct one (UTF-8 in most, but not all, cases).
We do, however, have some code which leverages this new API to setCharacterEncoding("UTF-8") -- which is, in fact, very nice to have. I can see that it can be obnoxious for implementation -- but users of the API do not and should not care.
Tomcat 5 has a lot of promising things over Tomcat 4.1 -- don't let spec non-compliance force those who are forced to care about rigorous i18n to tell our customers to use Tomcat 4.1 or pay for a commercial servlet engine if they want later spec compliance.
-- Jess Holle
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
