aspose file tools*
The moose likes JSF and the fly likes managed bean injection problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "managed bean injection problem" Watch "managed bean injection problem" New topic
Author

managed bean injection problem

Michael Schembri
Greenhorn

Joined: Aug 18, 2010
Posts: 12
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?

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16143
    
  21

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Michael Schembri
Greenhorn

Joined: Aug 18, 2010
Posts: 12
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

Joined: Jun 25, 2001
Posts: 16143
    
  21

"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

Joined: Aug 18, 2010
Posts: 12
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

Joined: Jun 25, 2001
Posts: 16143
    
  21

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

Joined: Aug 18, 2010
Posts: 12
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

Joined: Jun 25, 2001
Posts: 16143
    
  21

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: managed bean injection problem