I have fixed this in the head a few weeks ago. Facelets will now
provide to the JSF implementation a recommended encoding and
contentType. What the jsf implementation does with that is up to it.
Try doing a build from head to see if that fixes your problem.
Mike
On 10/31/06, Andrew Robinson <[EMAIL PROTECTED]> wrote:
You may want to cross post this with the facelets list as well. I am
doing so in this reply...
On 10/31/06, Randahl Fink Isaksen <[EMAIL PROTECTED]> wrote:
>
> I finally found out why the combination of Facelets 1.1.11 and MyFaces
> 1.1.4 makes it impossible to serve UTF-8. The problem is that they both
> expect each other to provide the encoding. First the FaceletViewHandler
> tries to make MyFaces decide which encoding to use by doing this:
>
> String encoding = null;
> ResponseWriter writer = renderKit.createResponseWriter(
> NullWriter.Instance, contentType, encoding);
> encoding = getResponseEncoding(context,
> writer.getCharacterEncoding());
>
> For now, just notice here that createResponseWriter() is invoked with an
> encoding of null. In MyFaces the default render kit is HtmlRenderKitImpl
> and when Facelets call createResponseWriter() with a null encoding
> MyFaces responds by doing this:
>
> if(characterEncoding==null)
> {
> characterEncoding = HtmlRendererUtils.DEFAULT_CHAR_ENCODING;
> }
>
> So MyFaces essentially says that if Facelets does not state explicetly
> which encoding it wants it just uses its default encoding, and
> DEFAULT_CHAR_ENCODING is in MyFaces equal to ISO-8859-1.
>
> Now, back to the first code snippet - in the last line of the shown
> FaceletViewHandler code above a method called getResponseEncoding() is
> invoked and it contains this code:
>
> if (encoding == null) {
> encoding = "UTF-8";
>
> This code will not have any effect because Facelets already invoked
> MyFaces with a null encoding which made MyFaces fall back to ISO-8859-1
> and thus the encoding is not null anymore.
>
> So is this a MyFaces bug or a Facelets bug? In the code above Facelets
> deliberately chooses not to decide for a specific character encoding
> thereby expecting that
>
> 1. the JSF implementation provides the developer with means for
> specifying which character encoding he wants and that
> 2. the render kit provided by the JSF implementation will return this
> desired character encoding
>
> This is in my opinion a wrong assumption - nothing in the JSF
> specification 1.1 says this is so. On the contrary the specification
> explicitly states that the encoding parameter is required when you
> invoke createReponseWriter, quote: "... the required value for the
> characterEncoding parameter for this method..." (section 8.1). So
> invoking createResponseWriter() with a null encoding is a violation of
> the specification, and thus I think this is a serious Facelets bug.
>
> I sincerely hope the Facelets developers will comment on this. Thank you.
>
> Randahl
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
