Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.0.1-core
-
None
Description
The LocaleElementsResourceLoader static initializer attempts to derive a locale elements library uri:
static private final ResourceLoader[] _ResourceLoaders =
;
The call to getLocaleElementsURI() ends up calling CoreRenderKitResourceLoader.getLocale(), which in turn does the following:
static public String getLocale()
{ String path = ((HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest()).getPathInfo(); String locStr = ""; int locIndex = path.indexOf("LocaleElements")+ "LocaleElements_".length(); int index = path.indexOf(_VERSION); if (index < 0) index = path.indexOf(".js"); if(index >= 0) locStr = path.substring(locIndex, index); return locStr; }Note that this code assumes that the request path returned from getPathInfo() corresponds to a LocaleElements library request. While this true during normal resource request processing (ie. when ResourceLoader.getResource() is called), this is not necessarily true when called from the LocaleElementsResourceLoader static initializer.
Depending on when the LocaleElementsResourceLoader is initialized, a call to getLocale() can result in:
1. A NullPointerException, if the FacesContext is not available, or if getRequest() happens to return null.
2. A StringIndexOutOfBoundsException from the substring() call, if the request path happens to be short.
3. A garbage return value, if one of the above two exceptions are not thrown.
As such, it is not safe for LocaleElementsResourceLoader to call into getLocaleElementsURI() from its static initializer.
Although this seems like a trivial issue, I specified the priority as "major" as we are seeing #2 in production environments.