FacesContext is null inside managed bean

[Peter Goldstein]

I'm having a somewhat unexpected problem with a null value returned by FacesContext.getCurrentInstance() inside a managed bean method invoked by a command button. Specifically, I have a login form with a button tag like this:

<h:commandButton action="#{authenticationBean.login}"
title="#{bundle.SubmitButtonTitle}"
value="Submit"/>

I have an authenticationBean mapped in my faces-config.xml like this:

<managed-bean>
<description>Used for managing user authentication.</description>
<managed-bean-name>authenticationBean</managed-bean-name>
<managed-bean-class>com.pmg.AuthenticationBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

and a navigation rule that looks like this:

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/protected/testParent.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>failure</from-outcome>
<to-view-id>/login.jsp</to-view-id>
</navigation-case>
</navigation-rule>
</faces-config>

The login method starts with:

public String login()
{
FacesContext facesContext = FacesContext.getCurrentInstance();
...

Now, this facesContext variable is set to null, and I don't understand how that's possible. Not only that, but if I comment out all calls to facesContext, then the navigation works fine and I'm directed to the intended target page.

This is all running on JBoss 4.0.3SP1

Anyone have any idea what the problem might be? I'm surprised by this, and don't really have any good idea how to debug the underlying problem. Any help would be greatly appreciated.

[Tim Holloway]

JSF isn't nearly as magic as it looks. Specifically, it's still running under HTTP's request/response limitations, so there's no permanently-running object to get a FacesContext from. The only way you can get a FacesContext is the Faces Servlet was the URL target. Or, to put it another way, the FacesContext is something built and destroyed for each HTTP request.

In other words, if you try and use a backing bean directly from a JSP or a traditional servlet, they will not set up the FacesContext for that request and if you attempt to aquire it, you'll get back null.

Personally, I prefer container-managed authorization to "do-it-yourself" logins. It's not as flexible, but I've never had any problems with that, and it makes coding easier (since it's mostly declarative) and it makes apps more portable.

[Peter Goldstein]

Tim, thank you for the reply, but I'm not sure I understand it.

The login bean is being invoked from a JSP that is processed by the FacesServlet. Specifically I've got a login.jsp, which is invoked from a browser using a URL (...)/login.faces, and the FacesServlet is configured to handle all URLs with a .faces extension.

As far as I can tell, the FacesServlet should be the target for this POST request - the submit button is created by a JSF tag, and hence I would assume a submission runs through the FacesServlet. Moreover, the navigation IS being handled by the configuration in faces-config.xml, so a FacesContext has to get created at some point or another. Also, I'm not accessing the bean directly, but rather through a JSF tag as described in my post.

Given the above, I'm not sure I understand your reply. Any clarification would be appreciated.

[Peter Goldstein]

I've resolved this problem, and am going to post for the future edification of anyone who may run into something similar.

This turned out to be a build/class loader issue. My build was copying the MyFaces jar files from the JBoss jsf-libs directory into the WEB-INF/lib for my application. This appears to have caused some kind of class loader collision, because my pages all rendered fine and one could access the FacesContext from them. However the backing beans stored in my jar file appear to be using a version of the FacesContext class loaded from the WEB-INF/lib directory. Despite being the exact same library files, the class loader was loading them again (presumably because of the web application class loading rules) and hence I was seeing a different version of the class.

So, in short, if you see a null FacesContext in backing beans on JBoss check your WEB-INF/lib and make sure you're not including any of the MyFaces jars.

[Tim Holloway]

Sorry. I misunderstood you. Most people who ask that question are invoking their backing bean directly from a JSP/servlet and not part of a Faces request. Which is OK, as long as you don't intend to access Faces services while doing it!

In your case, you got whacked by the old multiple classpath issue. That can be a real bear to figure out, so I'm glad you didn't have to spend forever on it!

[Ranjith Kumar]

Hi Peter,

I happen to get the same error but the myfaces jar files are not in the WEB-INF/lib as was in your case but in deploy\jbossweb-tomcat55.sar\jsf-libs. I removed the jsf-lib folder but still the FacesContext is returned as null. I have been breaking my head on this for the last 2 days. Hope you can help.

I am copying my code below �



Jsp:

<td width="20%" align="left">

<html:commandButton image="img/login.jpg" action="#{userBean.loginUser}" />

</td>





faces-config.xml



<navigation-rule>
<description>Login Screen</description>
<from-view-id>/jsp/login/login.jsp</from-view-id>
<navigation-case>
<from-outcome>failure</from-outcome>
<to-view-id>/jsp/login/login.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>success</from-outcome> <to-view-id>/jsp/setup/customer/addCustomer.jsp</to-view-id>
</navigation-case>
</navigation-rule>


managed-bean
<managed-bean>
<description>User bean</description>
<managed-bean-name>userBean</managed-bean-name>
<managed-bean-class>com.server.entity.User</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>


Can you tell me what listener class you have specified in your web.xml? I earlier had these lines in the web.xml �

<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>



But I removed them when I removed the jsf-lib folder. Any help will be greatly appreciated.
Thanks
Ranjith

[Ranjith Kumar]

I thought the error stack would be helpful in better understanding the problem -
10:45:38,796 INFO [STDOUT] java.lang.NullPointerException
10:45:38,796 INFO [STDOUT] at com.veloxe.server.entity.User.loginUser(User.java:184)
10:45:38,796 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:45:38,796 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10:45:38,796 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10:45:38,796 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:324)
10:45:38,796 INFO [STDOUT] at com.sun.faces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:126)
10:45:38,796 INFO [STDOUT] at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:72)
10:45:38,796 INFO [STDOUT] at javax.faces.component.UICommand.broadcast(UICommand.java:312)
10:45:38,796 INFO [STDOUT] at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:267)
10:45:38,796 INFO [STDOUT] at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:381)
10:45:38,796 INFO [STDOUT] at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:75)
10:45:38,796 INFO [STDOUT] at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
10:45:38,796 INFO [STDOUT] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
10:45:38,796 INFO [STDOUT] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja
va:252)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
10:45:38,796 INFO [STDOUT] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja
va:202)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
10:45:38,796 INFO [STDOUT] at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
10:45:38,796 INFO [STDOUT] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.jav
a:159)
10:45:38,796 INFO [STDOUT] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
10:45:38,796 INFO [STDOUT] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
10:45:38,796 INFO [STDOUT] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
10:45:38,796 INFO [STDOUT] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Pr
otocol.java:744)
10:45:38,796 INFO [STDOUT] at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
10:45:38,796 INFO [STDOUT] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
10:45:38,796 INFO [STDOUT] at java.lang.Thread.run(Thread.java:534)

[Peter Goldstein]

Ranjith,

I'm fairly confused by your comments in your post.

First, my issue was a result of a class collision between two different sets of MyFaces jars - each of which provided the JSF API and implementation. You've removed the jsf-libs subdirectory in Tomcat (which I really wouldn't recommend unless you've got a compelling reason). Where is your JSF implementation in your scenario? Did you add the JSF libs to your WEB-INF/lib? Your post makes this very unclear.

Second, you absolutely must have a listener specified in your web.xml. The exact listener class depends on which JSF implementation you're using. Assuming you're using JSF-RI, you need to include this:

<listener>
<listener-class>com.sun.faces.config.ConfigListener</listener-class>
</listener>

If MyFaces, you need to put back the listener segment you removed. Other implementations have different listener classes.

From the stack trace you posted it does appear that you've got the FacesServlet running and the URL mapping set up correctly. My first suspect would be the lack of a listener-class entry.

Anyway, if you can clarify some of the above - namely the implementation you're using, where the JSF classes are packaged, etc. - that would be helpful in resolving your problem.

Hope that's helpful.

Regards,

Peter

[Rajesh Santha]

Dear Friends,

I too puzzled with this error in my application. Excepting lot more help.

I solved FacesContext is null error, while the page is loading. But i couldn't solve when i click the button.

Take Care