You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Thomas Andraschko (JIRA)" <de...@myfaces.apache.org> on 2019/01/13 16:37:00 UTC

[jira] [Commented] (MYFACES-4250) NullPointerException triggered as consequence of FaceletsCompilerSupport.loadLibraries

    [ https://issues.apache.org/jira/browse/MYFACES-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741607#comment-16741607 ] 

Thomas Andraschko commented on MYFACES-4250:
--------------------------------------------

[~simon.geard] could you atleast provide a patch with your fix? So i can check it.

> 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)