File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes Upgrade to JSF 2.0 - Login not working - getUserPrincipal() is always null Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Upgrade to JSF 2.0 - Login not working - getUserPrincipal() is always null" Watch "Upgrade to JSF 2.0 - Login not working - getUserPrincipal() is always null" New topic
Author

Upgrade to JSF 2.0 - Login not working - getUserPrincipal() is always null

Harry Dhina
Greenhorn

Joined: May 11, 2005
Posts: 6
Sorry for cross posting. We are upgrading to JSF 2.0 (JBoss 6) and had a lot of issues with facelets and I think we have resolved most of the issues. But the login is still not working. The issue is with the LoginPhaseListener. Please let me know if you need any other part of the code:

Parts of the code:

login.xhtml

faces-config.xml



web.xml


LoginPhaseListener:



Please let know if I'm missing anything. I know the web.xml is messy and I have inherited the code recently & trying to clean up the code, but unable to. Thanks in advance

Harish
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

Your first - and biggest - problem is in using JSF for the login form.

When the container security mechanism takes over and presents a login, the code that handles the login process is not application code. JSF only works when the process is dispatched from the FacesServlet, and the container login is really only expecting a basic HTML form, although it can work with vanilla JSP pages. Depending on the server, not only login/loginfail screens, but welcome screens and exception error screens done in JSF may fail to operate properly, as all of these are invoked internally by the server.

Beyond that, if I feel the need to attach a user profile as a reference object based on the login userId, I'm most likely to do that on-demand, rather than explicitly and immediately. Saves overhead if I don't need the object. I actually normally access resources like that via a special static class (JSFUtils) that I write and put my container- and framework-dependent services into in order to keep the bulk of the app in POJO form. Doing that makes my code more portable and easier to test offline.

I don't recommend using a JSF listener to do what you are doing in any event, because it assumes that all application code MUST be JSF, and there are situations where a non-JSF servlet or JSP may be more appropriate, especially if you are generating non-HTML output like PDF's or Excel spreadsheets. The common denominator between JSF and non-JSF can be found in a ServletListener, where it's a lot easier to obtain the userId than it is in JSF code, especially since the FacesContext doesn't exist during non-JSF URL processing, but the request and response objects are always directly accessible in a ServletListener. Once the ServletListener has obtainer the user profile object, it simply stores it as a session-scope object, where ordinary J2EE code can use it in the traditional way and JSF can use it as a session-scoped backing bean.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Upgrade to JSF 2.0 - Login not working - getUserPrincipal() is always null