Major Description
The spec has a problem when it try to derive which resource should be resolved according to a locale.
All start on JSF 2.0 section 2.6.1.4. There is some pseudo code that says this:
function getLocalePrefix() {
var localePrefix;
var appBundleName = facesContext.application.messageBundle;
if (null != appBundleName)
// Any MissingResourceException instances that are encountered
// in the above code must be swallowed by this method, and null
// returned;
return localePrefix;
}
The problem start when to calculate the locale using facesContext.application.viewHandler.calculateLocale(). The description on the javadoc about this method says this:
"... Returns an appropriate Locale to use for this and subsequent requests for the current client...."
Ok. Now look spec section 7.5.1. :
public Locale calculateLocale(FacesContext context);
public String calculateRenderKitId(FacesContext context);
"... These methods are called from createView() to allow the new view to determine the Locale to be used for all subsequent requests, and to find out which renderKitId should be used for rendering the view. ..."
On "view" requests, when ViewHandler.createView() is called, calculateLocale() is called too and the locale is assigned to the viewRoot through UIViewRoot.setLocale(). Later, facelets ViewHandler or jsf ViewTag can override this value using an static string or a ValueExpression.
But, if the current request is a "resource" request, no viewRoot will be found, so calculateLocale() should be done. In this case the locale should be extracted in some way from the request path.
Doing some tests it seems Mojarra guys thought the same too, because they append a &loc=... for each resource, but that param is broken, because it is ignored when it is loaded. Anyway, it seems to be the way to go. Other minor changes will be committed too.