• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

managed bean injection problem

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm new to jsf and am trying to get started with a basic app using jsf, hibernate and spring.

basically, loginController has a method login() that sets the authenticatedUser property with the domain object returned by the service class.

in the "success" page, loginController is the same instance as in the login page, so i can access the user details using loginController.authenticatedUser, but authenticatedUser is empty..

so #{authenticatedUser.email} returns blank but #{loginController.authenticatedUser.email} returns the email for the user..

when injecting a managed bean into another, does jsf inject an object reference or a "copy" of the bean?

 
Saloon Keeper
Posts: 28468
210
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
Welcome to the JavaRanch, Mikel!

I strongly discourage writing your own security code instead of using the standard J2EE security system, no matter how many books you see with "login" code examples. For more detailed ranting on that subject, search this forum.

However, your real question is only incidental that that, and the answer to that question is no, the bean is not copied. It's a reference. Although if both beans are in request scope it might not look that way, since request-scope beans are created (and destroyed) on each view request. So they're not good as state-holders.
 
Michael Schembri
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, j2ee/Spring Security is on my to do list, I just started with a login page as it was the simplest scenario I could think of.

the authenticatedUser bean is in session scope, and the loginController is in the request scope..

it seems like it's working the other way round.. the controller instance is the same in login.jsp and welcome.jsp, whereas authenticatedUser is empty in welcome.jsf

Am I missing something?
 
Tim Holloway
Saloon Keeper
Posts: 28468
210
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
"Controller" is a misnomer here. Most of the MVC Controller functionality in JSF is in the FacesServlet and the tag processors. Backing Bean Action methods are really business methods, not controller methods, and the Backing Bean itself is the Model. And, yes, putting business functionality in a Model is corrupting the purity of the paradigm, but they had to go somewhere.

Your "LoginController" would typically be the Model (Backing Bean) for the login form and you'd inject the AuthenticatedUser into it. It would then process the login credentials injected from the View in its action method, and if satisfied, it would manipulate the AuthenticatedUser to reflect the user's authenticated session context. For example, by setting the user ID and security role properties.

Your problem may be due to postback issues. JSF is very big into postbacks, and they have issues with request-scope objects, because the back-and-forth that goes along with postback creates and destroys the current request object each time a request is made. The easy way to tell is to see if the problem goes away when you make the LoginController session-scoped.

JSF2 addresses this by adding a new scope (View scope), but JSF1 has to make do with session scope.
 
Michael Schembri
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The problem was that I (wrongly) assumed that setting the managed property would also set the managed bean injected into the property. In hindsight it makes sense that it wouldn't work.

it would have been nice to have a backing bean without jsf specific code (facesContext).. but i guess it's asking too much

RE controller, thanks for clearing it up.. is there a better naming convention?
 
Tim Holloway
Saloon Keeper
Posts: 28468
210
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
Backing Beans are MVC Model objects, although the action methods make them impure examples of that breed and listener methods do cause a small bit of controller functionality to be placed there as well. But their primary functionality is as a Model, so that's a good enough term for most purposes. I have found it necessary in a tiered architecture to stress that they're a GUI model and that the Domain (persistence) model should generally be a separate set of objects.

I'm not clear on why you don't think that making a managed bean be a managed property (injected) into another managed bean is inadequate. If you're maintaining the proper object relationships, the JSF framework can handle all that without any need for JSF-specific code in either of the beans.
 
Michael Schembri
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The problem was that I was setting the managed property with the domain object returned by the service layer. so the jsf framework was referencing a different object.

I had to use the facescontext to set the authenticatedUser managed bean.

So rather than exposing the persistance domain object, you keep an instance somewhere in the backing bean (e.g. for any possible updates to the record)?
 
Tim Holloway
Saloon Keeper
Posts: 28468
210
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
Yes. The Backing bean is essentially being used as a DTO to the domain model. That way changes to the GUI can be formally committed rather than simply updating the domain object directly. The action method typically obtains/creates a domain object and updates it with the properties from the backing bean. Depending on how complex the project is, that may involve direct access to persistence DAO/Service objects or passing through some sort of business tier.

Incidentally, back around February (give or take a year), we had a number of discussions in this forum about why domain model objects make poor backing beans.
 
The moth suit and wings road is much more exciting than taxes. Or this tiny ad:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
reply
    Bookmark Topic Watch Topic
  • New Topic