[
https://issues.apache.org/jira/browse/TRINIDAD-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Schwartz updated TRINIDAD-2340:
------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.2-core
Status: Resolved (was: Patch Available)
Avoid calling CoreRenderKitResourceLoader.getLocaleElementsURI() during
resource loader initialization, as it is not safe to depend on the request uri
at this time. Fortunately, this call was entirely unnecessary, so we can
simply remove it with no negative impact.
Added a small unit test that verifies that the CoreRenderKitResourceLoader (and
thus the LocaleElementsResourceLoader) can be instantiated without access to a
FacesContext (and thus is not dependent on any request-specific state).
> LocaleElementsResourceLoader init dependency on request path
> ------------------------------------------------------------
>
> Key: TRINIDAD-2340
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2340
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Affects Versions: 2.0.1-core
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Fix For: 2.0.2-core
>
> Attachments: trinidad-2340.patch
>
>
> The LocaleElementsResourceLoader static initializer attempts to derive a
> locale elements library uri:
> static private final ResourceLoader[] _ResourceLoaders =
> {
> new ClassLoaderResourceLoader(),
> new
> TrTranslationsResourceLoader(CoreRenderKitResourceLoader.getLocaleElementsURI("Translations",
> false))
> };
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
