[ https://issues.apache.org/jira/browse/MYFACES-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688380#comment-16688380 ]
Thomas Andraschko commented on MYFACES-4250: -------------------------------------------- I just wonder whats so special in your case, that no-one faced that error before? Could you provide the full stacktrace? > 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)