wood burning stoves 2.0*
The moose likes JSF and the fly likes FacesContext is null inside managed bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "FacesContext is null inside managed bean" Watch "FacesContext is null inside managed bean" New topic

FacesContext is null inside managed bean

Peter Goldstein

Joined: Feb 26, 2006
Posts: 15
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:

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

and a navigation rule that looks like this:

The login method starts with:

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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964

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.

Customer surveys are for companies who didn't pay proper attention to begin with.
Peter Goldstein

Joined: Feb 26, 2006
Posts: 15
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

Joined: Feb 26, 2006
Posts: 15
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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964

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

Joined: Mar 30, 2006
Posts: 6
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 �


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

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



<description>Login Screen</description>
<from-outcome>success</from-outcome> <to-view-id>/jsp/setup/customer/addCustomer.jsp</to-view-id>

<description>User bean</description>

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


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

Joined: Mar 30, 2006
Posts: 6
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
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
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
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
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

Joined: Feb 26, 2006
Posts: 15

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:


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.


Rajesh Santha

Joined: Nov 17, 2009
Posts: 1
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
Don't get me started about those stupid light bulbs.
subject: FacesContext is null inside managed bean
Similar Threads
How to create a secure login system?
navigation rules are not working...
DataTable problem
JSF Action
simple logic to authenticate users