Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

[Resolved] Services as Managed Beans

 
Henry Lowell
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18012
47
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Henry Lowell
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18012
47
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic