Hi Robb, good solution. I suppose this is why it is called 'bleeding edge'!
I see tomcat 5 implements servlet spec 2.4 - that is a relief.
I checked out the servlet spec 2.4, as you said, there is the following element-list in web.xml specified as 1 or more:
<locale-encoding-mapping-list>
<locale-encoding-mapping>
<locale>ja</locale>
<encoding>Shift_JIS</encoding>
</locale-encoding-mapping>
</locale-encoding-mapping-list>I shall try it out.
Guess I have to learn to be even more bleeding edge and then I won't spend hours wondering what's up!
Thanks for the advice.
Regards Adam
On 09/29/2003 12:40 PM Nedwick, Robert wrote:
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
-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
