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]
