wood burning stoves 2.0*
The moose likes JSF and the fly likes [Resolved] Services as Managed Beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "[Resolved] Services as Managed Beans" Watch "[Resolved] Services as Managed Beans" New topic
Author

[Resolved] Services as Managed Beans

Henry Lowell
Ranch Hand

Joined: May 29, 2006
Posts: 63
We can't use Spring in our current project. I won't go into why. But we are using JSF so I figured I could use JSF's managed bean facility to do what I normally use Spring for and that is to inject DAO's into Service classes and access those service classes within the application.

Actually, let me back up. First, I created my own ServletContextListener that read my own really simple XML file and did the same thing. I threw all the services in application scope. But as I was configuring my backing beans for the JSF pages, I realized I could probably do the exact same thing I was doing with my own listener using the managed bean facility.

So what I do is declare a bean for my DAO and then declare a bean for my Service and inject that dao into the service using the managed-property (sound familiar?). Because there are parts of the application that doesn't use JSF but still needs access to the services, I have to place both the dao bean and the service bean in session scope.

My question is, does anyone see a downside to this? Any gotchas?
[ June 16, 2006: Message edited by: Henry Lowell ]

Hank
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

That's a good question. I recently did an app that used Spring to manage the persistency mechanism and then injected them into JSF using that handy little adapter they provide. In retrospect, I suppose that JSF could have handled it all except that I'd have had to do my own transaction management instead of having Spring handle it for me via the AOP fcility.

I was slow in picking up Spring, but I'm quite partial to it now, since it reduces the amount of duplicated overhead code I have to generate and it's very lightweight.


Customer surveys are for companies who didn't pay proper attention to begin with.
Henry Lowell
Ranch Hand

Joined: May 29, 2006
Posts: 63
The only thing that comes to mind immediatly is threading issues. However, I don't see how that would be any different from Spring. Do you or does anyone happen to know in what context/scope spring persisted beans are kept? Application, Session, ...? That may be the only real difference.
Henry Lowell
Ranch Hand

Joined: May 29, 2006
Posts: 63
Ok, I have run into a problem. The service beans from the manged bean facility aren't available to non JSF code. So if I code up a servlet and try and grab one of my services from session, since the JSF cycle hasn't kicked off the creation of said bean yet because no JSF view has been rendered and requested the bean, it doesn't exist.

So unless someone knows how to force JSF to create the bean outside of a JSF page, I am out of luck.
Henry Lowell
Ranch Hand

Joined: May 29, 2006
Posts: 63
Problem solved. I ran across this on the JSF mailing list. (Thanks Julian).



I put this in an abstract class that my servlets extend. Works great!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

Originally posted by Henry Lowell:
The only thing that comes to mind immediatly is threading issues. However, I don't see how that would be any different from Spring. Do you or does anyone happen to know in what context/scope spring persisted beans are kept? Application, Session, ...? That may be the only real difference.


I think that the Spring factory implementation determines that. It should either be global (outside of J2EE scopes entirely) or application scope. Unless I've missed something.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: [Resolved] Services as Managed Beans