wood burning stoves 2.0*
The moose likes JSF and the fly likes FacesContext is Null : Seeking Explanation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "FacesContext is Null : Seeking Explanation" Watch "FacesContext is Null : Seeking Explanation" New topic
Author

FacesContext is Null : Seeking Explanation

Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 43
I am using JSF1.1 on Weblogic Server 9.2.
I have a project which consits of 9 subprojects.
All the subprojects are bundled in one EAR for deployment.

Off these 9 projects, 1 is web project, 1 is EJB project,1 is EJBClient and other are JAVA projects.
I have implemented SAML for single sign-on.
When accessing the FacesContext in the web project using FacesContext fc = FacesContext.getCurrentInstance();, it works fine.

When trying to access FacesContext in a Java project (and not the web-project) in non SAML EAR (Web.xml and Weblogic.xml not having SAML tags), everything runs fine, but when SAML EAR is deployed and application is accessed from another application, the FacesContext is fetched as null in this Java Project.

For me, the problem appears to be trying to access FacesContext outside the web-project.
As a solution I have removed the FacesContext reference from ouside the web-project.
Could anyone please provide an explanation to why this FacesContext is fetched as null?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15947
    
  19

The FacesContext is not a durable object.

It is created when a JSF URL request is received by the FacesServlet and used as the resource anchor point for JSF lifecycle processing. Once that URL request has run to its conclusion and the Http Response has been sent, the FacesContext is destroyed. Non-JSF URLs don't get dispatched to the FacesServlet, and therefore no FacesContext is constructed, so attempting to fetch one will return NULL.

Don't even think about trying to cache away a FacesContext for later use. It doesn't work that way.


Customer surveys are for companies who didn't pay proper attention to begin with.
Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 43
Thanks Tim.
In my application the request from appA(source site for single sign on) is made using a url similar to following:
https://domainURL/projectContext/index.jsp ,
is it advisable to change this to https://domainURL/projectContext/index.jsf , so that the request passes through FacesServlet and FaceContext is created for this request?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15947
    
  19

The question is: Why do you need the FacesContext?
Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 43
It was used to access sessionMap to put values in the map for later use, as following:

FacesContext fc = FacesContext.getCurrentInstance();
Map<String, Object> m = fc.getExternalContext().getSessionMap();
m.put("attributeName", "attributeValue");
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15947
    
  19

You do not need FacesContext for that.

JSF session-scope objects are J2EE session scope objects. Therefore, a servlet can do a request.getSession(true).putAttribute("name", value) and the object will be visible as a JSF session-scope object. Since normally JSF session scope objects are Managed Beans, however, and you'd be initializing the property directly, the ManagedProperties would not be automatically set - you would have to do that manually.

It is likewise true that Servlets and JSPs can access JSF session-scope objects, since, as I said, JSF session scope is J2EE HttpSession scope. The only difference is what mechanisms are used to instantiate and initialize them. Once created and placed in the session, there's no way to tell the difference.
Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 43
Thanks Tim.
I would like to deviate from the topic a little and like to clarify whether this is a good practice to use request.getSession(false) instead of using request.getSession(true) in order to ensure that new session is not created after the user has logged into the application and session has timed out.
The approach which I follow is, that the session is created at the time of login using request.getSession(true) and at all later points in the application I use request.getSession(false) to use session attributes. It will help if you can confirm whether this is a valid approach.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15947
    
  19

For the example that I gave, that would have thrown a NullPointerException, but then again, it wasn't intended to be real-world code.

In actuality, I simply don't recommend using login/security systems that are based on user-designed security frameworks to begin with. J2EE has a perfectly good security mechanism built right into it, and unlike the typical in-house developed systems, it was designed by people who were formally trained in security and didn't have other "more important" things to distract them while they did it.

Using the standard container-managed security, you don't need to pass parameters in from an external source (which can be a security risk) and you can trivially tell when someone is logged in because the HttpSerlvetRequest userId property (and userPrincipal property) are not null, and contain the guaranteed real login ID of the user without having to cook up mechanisms for passing it in.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: FacesContext is Null : Seeking Explanation
 
Similar Threads
EJB3.0 deployed on WAS7.0 does not work on remote beans ?
EARs, logging and dependant jar files
j2ee project dependency and project reference
How to refer web project from ejb project
WSAD and Web Projects