• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

FacesContext is Null : Seeking Explanation

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Abhishk Singh
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The question is: Why do you need the FacesContext?
 
Abhishk Singh
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic