• 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 ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

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

Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:





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

Saloon Keeper
Posts: 27856
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
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.
Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic