Also, I believe that some application servers will cluster the servlet context along with the httpsessions.
BAL
From: Joe Germuska <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Subject: Re: Storing global data in the servletContext Date: Sun, 9 May 2004 09:05:13 -0500
At 9:37 AM -0400 5/9/04, Brian Alexander Lee wrote:That's interesting, so you recommend having an EJB (running in the ejb container) to manage data put into user sessions and servlet contexts (running in the web container)?
I wouldn't go that far -- but then again, I'm not much of an EJB developer either. Never needed 'em.
What's the advantage to this technique?
It's shared between clusters, and the ServletContext is not. That was the original question -- how to share things that are "application scoped" in a clustered environment.
Looking back at the original email, I would guess that the things read from XML config files could pretty safely be stored in each ServletContext -- assuming they don't change after initialization -- drop down menus seem to fit that description.
My other statement, about "using one bean to manage everything in an application context" certainly didn't mean one *enterprise java* bean. Like I said, I don't use 'em. But if you have a bunch of things that go into the application context, you may find it cleaner to make one "Application" bean which goes into the application context and which stores all those other things as properties. Then you never have to worry about making sure all accesses into the context use the right name, except for one object, and you get type-safety as much as you want it, and you have a clear interface for your application object which you could use in testing, etc.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."
-- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
