JBossDeveloper

My bad Thomas, I thought that you proposed that Seam would do the filter creation and application.

Long story short, from lws688 it sounds like facelets was misinterpreting a request header and applying an incorrect charset. So the current issue appears to be resolved.

Going deeper into charsets...

Browsers detect content encoding in a number of ways. The most preferred is the Content-Type HTTP header because the browser can set the encoding before creating the DOM. Because JSP pages are compiled into Servlets it's possible to tell the JSP container to generate the appropriate servlet API calls to set this header. There are various JSP markups to achieve this.

To set charset to windows-1252.

<%@ page contentType="text/html;charset=windows-1252"%>

jspx style

<?xml version='1.0' encoding='windows-1252'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:h="http://java.sun.com/jsf/html"
 <jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
 doctype-system="http://www.w3.org/TR/html4/loose.dtd"
 doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
 <jsp:directive.page contentType="text/html;charset=windows-1252"/>

Before dynamically generated content, the Content-Type header wasn't typically set, and browsers needed to interrogate the markup. The meta header tag is used to tip off the browser in that case.

<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"/>

Absent any of this information, the browser will use its default charset.

Of course each browser works differently, so it's important to be consistent. Some browsers will ignore any markup declarations if a Content-Type header is present. Others ignore the header and look for charset info in the markup.

It sounds like there was a bug in the facelets compiler that most likely caused it to incorrectly set the Content-Type header. I'm glad everything is working now. My original point though, is that HTML and JSP and JSF provide almost standard ways for setting the charset encoding on a page by page basis. It should be very rare that an external filter would be needed to augment or override the developer's declarations. In fact, if accidentally misapplied, the filter could cause subtle bugs.

If Seam wants to provide such a filter for these corner cases, that's fine with me, weblogic provides similar functionality within weblogic.xml.

<charset-params>
 <input-charset>
 <resource-path>/*</resource-path>
 <java-charset-name>UTF-8</java-charset-name>
 </input-charset>
</charset-params>

Just realize that once you open Pandora's box, you may get a lot of additional requests, either to support Weblogic's style config or something else. I'd suggest looking at the immediate need for such a feature. When JSP/JSF/Facelets are working correctly this feature isn't necessary. If down the road you get a request from someone that has statically generated content without a meta tag and needs filter support, then see how such a thing would fit into the current architecture and how it may snowball down the road.

If other frameworks provide such a filter, and Seam needs to stay feature for feature matrix competitive, I understand. However, I'd recommend the filter be the last tool reached for. Instead I'd favor the above charset declarations as the recommended approach.

Regards,
Jim