[TRINIDAD-2419] Need to check validity of FacesContext for before servicing resource requests

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0.1-core
• Fix Version/s: 2.1.0-core
• Component/s: Archetype
• Assignee: Gabrielle Crawford
• Reporter: Prakash Udupa
• Created: 07/Oct/13 20:18
• Updated: 09/Oct/13 18:39
• Resolved: 09/Oct/13 18:39

Description

We have been seeing issues with our automated tests failing in a farm environment due to a valid FacesContext not being available for a request, particularly for a request for a resource. The logs show the following errors when this happens:

FacesContext: com.sun.faces.config.InitFacesContext@1b5e765
ServletContext: null
java.lang.NullPointerException
at org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocale(CoreRenderKitResourceLoader.java:87)
at org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocaleElementsURI(CoreRenderKitResourceLoader.java:76)
at org.apache.myfaces.trinidadinternal.resource.LocaleElementsResourceLoader._getLibraries(LocaleElementsResourceLoader.java:103)
at org.apache.myfaces.trinidadinternal.resource.LocaleElementsResourceLoader.getURL(LocaleElementsResourceLoader.java:69)
at org.apache.myfaces.trinidadinternal.resource.LocaleElementsResourceLoader.findResource(LocaleElementsResourceLoader.java:55)
at org.apache.myfaces.trinidad.resource.ResourceLoader.getResource(ResourceLoader.java:67)
at org.apache.myfaces.trinidad.resource.RegexResourceLoader.findResource(RegexResourceLoader.java:69)
at org.apache.myfaces.trinidad.resource.ResourceLoader.getResource(ResourceLoader.java:67)
at org.apache.myfaces.trinidad.resource.CachingResourceLoader.findResource(CachingResourceLoader.java:74)
at org.apache.myfaces.trinidad.resource.ResourceLoader.getResource(ResourceLoader.java:67)
at org.apache.myfaces.trinidad.webapp.ResourceServlet.getLastModified(ResourceServlet.java:260)
at avax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
at org.apache.myfaces.trinidad.webapp.ResourceServlet.service(ResourceServlet.java:170)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:341)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:137)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:460)
at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:120)
at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:217)
at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:81)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)

We could trace this back to some variant of the following implementation issue in Mojarra runtime.
https://java.net/jira/browse/JAVASERVERFACES-2533

The issue is that the FacesContext is not being cleaned up properly, so new requests could get hold of an invalid but non null FacesContext hanging around.

A solution for this is for the ResourceServlet to check and see if we have a bogus FacesContext, in which case, discard it and recreate a good one. The suggested code change is a simple addition to an existing code that checks for a non-null FacesContext.