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 ]
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.
So unless someone knows how to force JSF to create the bean outside of a JSF page, I am out of luck.
I put this in an abstract class that my servlets extend. Works great!
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.