Format tags (like fmt:formatDate) use Locale locale = SetLocaleSupport.getFormattingLocale( pageContext, this, true, DateFormat.getAvailableLocales()); Since the third parameter is "true", SetLocaleSupport.getFormattingLocale will eventually do: setResponseLocale(pc, XXXXXXX); which directly results in: response.setLocale(XXXXXXX); The problem is: *each* format tag sets response locale. This works well under Tomcat but throws and exception under OC4J 9.0.2 ("java.lang.IllegalStateException: Response is already committed!") After all, if I have multiple formatDate with different locales (say Russian and German). What is response locale supposed to be? I suppose the only need for response.setLocale is to define response character set. We explicitly set output encoding to UTF-8, but the very first formatDate replaces it with different value. Format tags should not change locale which was already set (either explicitly by the setLocale or implicitly by another format tag).
The behavior of the formatting tags is in accordance with the JSTL spec. This being said, let's see what can be done with your specific situation. With respect to the following exception: "java.lang.IllegalStateException: Response is already committed!" the spec clearly states in section 8.4 that: "This assumes that the response is buffered with a big enough buffer size, since ServletResponse.setLocale() and ServletResponse.setContentType() must be called before ServletResponse.getWriter() in order for the specified locale or charset to affect the construction of the writer.(1) (1). It also assumes that the JSP container doesn't call getWriter() until it's about to flush the buffer. An errata has been published for the JSP 1.2 specification to clarify this." You should make sure that you have a big enough buffer, as well as verify that your container vendor complies with this errata of the JSP spec. With respect to the following comment: > After all, if I have multiple formatDate with different locales (say Russian > and German). What is response locale supposed to be? I suppose the only need > for response.setLocale is to define response character set. We explicitly set > output encoding to UTF-8, but the very first formatDate replaces it with > different value. Such a situation, where multiple locales are used in a single page, is not what I would think a common use case for internationalization. I agree with you however that setting the locale repetitively with different values is wrong in such a case. The current workaround would be to add a Java statement after the last formatting tag to reset the content-type and character encoding of the response. Not ideal, I agree. In a better world, we should probably check whether the char encoding has been set explicitely for the page, and refrain from re-setting it in such situations. This would require a spec change. I've filed this as an item to discuss with the expert group for JSTL.next.