[
https://issues.apache.org/jira/browse/MYFACES-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687843#comment-16687843
]
Thomas Andraschko commented on MYFACES-4250:
--------------------------------------------
[~simon.geard] ping ;)
> 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.2.12, 2.3.1
> Reporter: Simon Geard
> Priority: Major
>
> 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)
