The following code works with EA3 version, however, in the beta1, it fails to find the corresponding resource bundle file (Resources_cn_CN.properties)as the "cn_CN" is not correct country/language code, the resource bundle file has to rename to Resources_cn_CN.properties - zh_CN is the correct country/language code to make it work. ... <fmt:locale value="cn_CN"/> <fmt:bundle basename="com.sun.resources.Resources"> ... However, enforcing correct country/language code is not expected bahavior for fmt tags right now.
I noticed the cn_CN resource bundle does get found, but for some reason the keyword "engineer_name" gets mapped to "???". If in Resources_cn_CN.properties I replace engineer_name=\u5de5\u7a0b\u5e08 with engineer_name=some test value I get the correct result ("some test value") on the page. Note that if the resource bundle weren't found, you'd get ???engineer_name??? on the page, instead of just "???". So I believe JSTL works fine, but I still don't understand why the message key "engineer_name" maps to "???" when using cn_CN, and maps to the appropriate localized message when using zh_CN.
The behaviour you are seeing is not inherent to JSTL, but the container it is deployed with. As I said in my previous evaluation, the "???" in the output does not mean that the requested resource bundle cannot be found. In that case, you would have seen an error message of the form "???engineer_name???". The "???" means that the 3 characters your message key gets mapped to cannot be displayed properly. Note that in your example, the <fmt:bundle> action sets the response encoding by calling the response's setLocale() method with the resource bundle locale. When you set the page's locale to "cn_CN" (using <fmt:locale>), the resource bundle (and hence response) locale will be "cn_CN". Similarly, when you set the page's locale to "zh_CN", your resource bundle (and hence response) locale will be "zh_CN" (since you provided resource bundles for either locale). Now it is up to the container to map the response locale to an appropriate response charset. Tomcat uses the mapping specified in its org/apache/catalina/util/CharsetMapperDefault.properties resource. The mapping contains this entry (among others): zh=GB2312 meaning that any response locale with a language component of "zh" will be mapped to the GB2312 charset. There is no mapping for "cn". If you see "???" in the page output, it means that the container did not map the response locale to the appropriate response charset. JSTL also relies on the container to grant the most recent call to ServletResponse.setLocale() precendence over any previous calls and 'contentType' page directive. This requirement on the container will be published as an errata to JSP 1.2. If your container currenly does not implement this requirement, the setLocale() call by your <fmt:bundle> action will be ignored, resulting in the "???" output (unless you explicitly set the response encoding to "GB2312" via a page directive).