The behavior of the formatting tags is in accordance with the
JSTL spec.
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."
As you mentioned, you have to 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.
Finally, the language regarding this whole issue as been clarified in JSTL 1.1 as follows:
Summary: Response Encoding The way formatting actions influence the encoding of the response has been clarified in sections 8.4 and 8.10. Repeated calls to ServletResponse.setLocale() will affect the character encoding of the response only if it has not already been set explicitely.
Please check the JSTL 1.1 spec for more details (http://java/sun/com/jstl)
Hope this helps,
-- Pierre
MEIN, Christopher, FM wrote:
Hello
We have been having trouble with the formatDate and formatNumber tags. I have outlined in some detail an issue in the bug tracker (22892) but in brief every time a format tag runs if no Locale is set it creates a default Locale and then calls ServletResponse.setLocale(). Reading the JavaDoc for ServletResponse.setLocale()
Sets the locale of the response, setting the headers (including the Content-Type's charset) as appropriate. This method should be called before a call to getWriter().
What happens on our large pages is that, running under OC4J, we get a IllegalStateException response already committed error. Removing the formatDate tag corrects the problem. the same occurs with formatNumber.
My main question is why is the code in org.apache.taglibs.standard.tag.common.fmt.SetLocaleSupport
static void setResponseLocale(PageContext pc, Locale locale) { // set response locale ServletResponse response = pc.getResponse(); response.setLocale(locale);
// get response character encoding and store it in session attribute if (pc.getSession() != null) { pc.setAttribute(RequestEncodingSupport.REQUEST_CHAR_SET, response.getCharacterEncoding(), PageContext.SESSION_SCOPE); } }
written like it is? The Locale value gets set every time the tag runs so it isn't being cached properly in any case. I am wondering if anybody else is getting this type of error?
We have worked around the problem by commenting out the offending line. I think the caching of the Locale needs to be looked at as the Locale is always calculated as well.
Chris Mein
*********************************************************************************** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority
Visit our website at http://www.rbs.co.uk/CBFM/ ***********************************************************************************
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
