thanks for the quote. I did read that before but just didn't realise its significance.
I could have stayed with the struts bean taglib, but I spent a couple of days last month changing over, because JSTL has more flexibility. :(
The quotation from the JSTL spec in my eyes shows a flaw in someone's thinking, or a lack of understanding on my part - how can a character encoding be associated with a locale?
A locale has a country code and a language code, but no character encoding associated with it. I assume that ServletResponse.setLocale() uses the default app server encoding. Or is that configurable somewhere, like logging.properties?
My last hope is that the words "sets the charset header as appropriate" leave some way of stipulating what 'appropriate' actually is.
Do you agree that this is a deficiency in the JSTL specification? If so I will gladly go away and take up the issue with the JSTL expert group. If not, what would you recommend?
Adam
On 09/29/2003 09:34 AM Martin van Dijken wrote:
Hey Adam,
The behaviour you describe seems to be according to specifications. I've inlined section 8.4 of the spec below. This describes that you cannot use tags that establish a Localization context if you want to prevent setLocale being called. I'm guessing that's not altogether a big help to you since it seems the taglib becomes a pain in the ass more than a convenience, but you can't blame me for that;)
I'm not 100% certain how well they still work but you might want to give the jakarta I18N taglib a shot. I don't think they're in active development any more, but they might be just what you need.
Grtz,
Martin
8.4:
Any i18n action that establishes a localization context is responsible for setting the response's locale of its page, unless the localization context that was established does not have any locale. This is done by calling method ServletResponse.setLocale() with the locale of the localization context. 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.
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.
More specifically, the response's setLocale() method is always called by the <fmt:setLocale> action (see Section 8.5). In addition, it is called by the following actions: Any <fmt:bundle> (see Section 8.6) and <fmt:setBundle> (see Section 8.7) action. Any <fmt:message> action that establishes an i18n localization context Any formatting action that establishes a formatting locale on its own (see Section 9.3).
After an action has called ServletResponse.setLocale(), and sessions are enabled, it must determine the character encoding associated with the response locale (by calling ServletResponse.getCharacterEncoding()) and store it in the scoped variable javax.servlet.jsp.jstl.fmt.request.charset in session scope. This attribute may be used by the <fmt:requestEncoding> action (see Section 8.10) in a page invoked by a form included in the response to set the request charset to the same as the response charset. This makes it possible for the container to decode the form parameter values properly, since browsers typically encode form field values using the response's charset.
-----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: zondag 28 september 2003 23:21 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:
"Sets the locale of the response, setting the headers (including the Content-Type's charset) as appropriate"
thus overwriting what I set with my JSP page contentType= directive.
Would this a bug in Sun's implementation, a bug in MessageTag, or not a bug at all?
I see it as a problem because I cannot control what ServletResponse.setLocale() does to the http headers. A locale is ignorant of the character encoding, so it seems strange taht calling this method should affect the http character encoding header.
I see there's an entry in bugzilla already from a couple of weeks ago:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23125
On 09/28/2003 05:54 PM Adam Hardy wrote:
I'm trying to set my pages to UTF-8. I am setting my page
directive with:
<% page contentType="text/html; charset=UTF-8" %>
and so long as I don't use the JSTL fmt taglibs, it works.
When I put in
something like <fmt:message key="general.browserTitle" />
then UTF-8 is
overridden and response content type is set to ISO-8859-1.
On digging around I can't really see obviously in the
source when the
response.setContentType is called, but I can see that the
sessions are
getting this attribute set:
javax.servlet.jsp.jstl.fmt.request.charset==ISO-8859-1
although it doesn't seem to be the cause, just another
symptom. I have
tried <fmt:requestEncoding value="UTF-8" /> with no success.
I am using a filter in tomcat to set the request encoding
anyway, and
this is always UTF-8.
I'd appreciate any help on this, I've must have spent about 6 hours trying to nail this glitch.
Thanks Adam
-- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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]
