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?
The good thing about being a nobody is that you are perfect.
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.
An IDE is no substitute for an Intelligent Developer.
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.
Joined: Aug 19, 2010
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.
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.