Simon Geard created MYFACES-4250:
------------------------------------
Summary: NullPointerException triggered as consequence of
FaceletsCompilerSupport.loadLibraries
Key: MYFACES-4250
URL: https://issues.apache.org/jira/browse/MYFACES-4250
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.3.1, 2.2.12
Reporter: Simon Geard
I've recently been investigating a problem with our product, whereby the first
time a JSF-based screen loads, it fails with the following error in the logs:
{{Caused By: java.lang.NullPointerException}}
{{ at
org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(FaceletStateValueExpression.java:86)}}
{{ at
org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:118)}}
{{ at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:99)}}
{{ at com.sun.el.parser.AstValue.getValue(AstValue.java:179)}}
{{ at
com.sun.el.parser.AstDeferredExpression.getValue(AstDeferredExpression.java:63)}}
After some effort debugging, I found that the immediate cause of the NPE is
that on the first line of the getWrapped(ELContext) method, the FacesContext is
obtained from the ELContext, rather than by calling
FacesContext.getCurrentInstance. The FacesContext obtained this way is not the
same FacesContext that's being used elsewhere in the stacktrace, and the
UIViewRoot it supplies is likewise not the same one used elsewhere... this
incorrect view root does not contain the facelet state instance, so the 'map'
variable is null, causing the exception.
Digging further, I found that the source of the incorrect FacesContext and
UIViewRoot is the FaceletsCompilerSupport class, and that my problem relates to
the bug MYFACES-3830. The short version is that for the purpose of figuring out
all the annotation driven components and renderers, FaceletsCompilerSupport
creates a dummy FacesContext wrapping the real one (and view root), which it
de-registers once it's done.
However, some of the code which uses that FacesContext asks for the ELContext,
which causes an ELContext to be created - and the ELContext holds a reference
to the FacesContext as at the time it was created, which is the unwanted one
from FaceletsCompilerSupport.
I can "fix" the problem for my purposes by patching the
LoadComponentTagDeclarationFacesContextWrapper to push the correct FacesContext
into the ELContext during teardown (the restoreCurrentFacesContext method), but
I'm not sure if that's a good production fix...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
