> -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 28, 2003 5:21 PM > To: Adam Hardy > Cc: Tag Libraries Users List > Subject: JSTL & character encoding > > > In <fmt:message key=".."/> the class > ...tag.common.fmt.SetLocaleSupport's method setResponseLocale() is > called after fetching the localizationContext and before getting the > bundle. > > In setResponseLocale(), the response's locale is set via > response.setLocale(). This method according to the API also:
Adam, I had this same issue several months ago when we were moving our application over to use UTF-8. We managed to find a workaround that I describe below. I do not believe it is a bug in the JSTL implementation though, since the behavior you are seeing is in fact, described in the specification (see Section 8.4 Response Encoding of the JSTL 1.0 specification for details on how the JSTL <fmt> tag library may override the response locale). I don't really understand why the behavior that is described in the specification is desirable, especially since the JSTL is overriding explicit page directives that set the response character set, and you don't have a clue that it is doing it unless you're aware of this side effect of the <fmt> tag library. I never got a response to a similar question that I had posted on one of the tag lib mailing lists, but based on the fact that its so well documented in the spec, I believe that someone must have had a reason for this behavior. I think that part of the problem is that the next servlet specification (2.4) provides a standard method of mapping of a Locale to a character encoding via web.xml, and therefore the JSTL could perform the setLocale() method in such a way that your page encoding was not messed up. Anyway, the solution that I came up with was to use a ServletFilter that intercepted all calls to our presentation tier. The filter would set the request encoding and the response charset to UTF-8. It would also pass a custom subclass of HttpServletResponseWrapper named UTF8Response to the next item in the chain. UTF8Response basically just any method that could set the response character set to be an empty operation. It also would always return UTF-8 for the response character set. By using the custom response class, in conjunction with the ServletFilter, we managed to get everything to work fine in Tomcat 4.1, Oracle 9iAS 9.0.3, and Weblogic 6.1 (service pack 5 is required for Weblogic 6.1 due to bugs in the ServletFilter implementation 6.1). FYI, Oracle 9iAS still has some other character encoding issues with JSP tags that use BodyContent so the Oracle container still doesn't work 100% even after using the filter/response wrapper. Let me know if you have need any more details than this. Good Luck, Robb --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
