The MailReader 1.3 application handles this with a plugin. The plugin runs once when the application starts up and seeds application scope with a global reference to the DAO as well as "static" data for a drop-down. The Shale version does this with a listener. The Action2 version is using a listener now, but a Spring solution might be better.
My own preference would be to use Spring to create an instant singleton representating whatever dataset you needed. This is also a good way to handle "static" utility methods, without the downside of static classes. HTH, Ted. On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hello, > > I'm looking for an elegant and simple solution to something that I'm sure > others have dealt with already. Don't want to reinvent the wheel so I > thought might help to hear from others on how they're handling it. > > We have many webapps that need access to some common (mostly static) data > for doing validations or populating dropdowns, radio buttons, etc. Some > examples are lists of operating companies, company locations and/or company > holidays, etc. > > A long time ago, someone here coded a "utility" class with static methods. > The static methods return values which are hardcoded in the code. This > works OK as long as the data NEVER changes. If it does, we have to > recompile the class and tell everyone to get the new copy of the class in > their app. > > I thought a cleaner way would be to have a servlet that starts when the > webapp starts. The servlet would look up the values in some database (or > properties file(s)) and place the values in the app context. Initially, we > thought about doing this at the time a user logs into the site but storing > that info in everybody's session is inefficient. > > How have others dealt with this? Thanks for any feedback. > > > David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
