I was actually hoping to have it implemented where the entire store would be able to be updated on-the-fly and not have the application cache it on initialization. I would at least think that the MessageResources or MessageResourceFactory implementation would have a reload() method so the entire app didn't need to be reloaded to update the cached properties. This type of thing could even be configurable (like Craig suggested).
-----Original Message----- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 12:25 PM To: 'Struts Users Mailing List' Subject: RE: [New Functionality] ApplicationResources.properties to DB? My idea is to gather the properties into a static java.util.Properties object from a call to a stored procedure and instantiate it in context scope at application startup using the java -d argument to set the environment and filename in the system properties. The properties would then be available to any calling method, same as if fetching from a textfile. Mark -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 3:11 PM I don't know how helpful that would be. I love it for a persistence framework, but it seems like it might possibly be (mega-)over-kill for this task. Although! ... that would certainly take away any confusion about what the table/field names were (just map your classes to your tables)! The down-side would be that, not only would you have to instantiate your bundle, but you'd also have to instantiate an object for *every single* key/value pair (that got used). Regards, Eddie -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>