On May 14, 2010, at 12:53 PM, Mark H. Wood wrote: > On Fri, May 14, 2010 at 02:17:01PM +0000, Tim Donohue (JIRA) wrote: >> (Sidenote: Eventually, someday, I feel we should move the majority of all >> configurations to the Admin UI -- so that there's no need to stop/start >> Tomcat/DSpace every time you need to modify dspace.cfg. However, in order >> to achieve this, we need to *trust* that the System Administrator knows what >> he/she is doing -- they should be allowed to make any change in the system.) > > If runtime reconfiguration is a goal, we need to agree on it (and I'm > not disagreeing here) and then go through the code to make sure that > we *always* call the ConfigurationManager for settings instead of > e.g. caching config. data via static initializers.
We should be using the DSpace Service ConfigurationService for such support. Application code can listen to the ConfigurationService for configuration changes and act accordingly. > > Item for next week's agenda? What I'd really like to see is a discussion that involves more "buy-in" to the dspace -services support. Likewise, while doing the various GSoC projects we will want to review all the configuration parameters and discuss which should remain in the config files , database, and more importantly which should leave the configuration altogether in favor of being supported in the Spring and other framework configuration that is applied when an Addon Module is added into your DSpace instance. > We'll also need to stare hard at each of the configuration variables > and work out which ones make sense to adjust at runtime. The only ones I would be really concerned with are the ones that configure the database connection (strictly because changing them may break the above process if they are stored in that database). Likewise, any "plugin" driven configuration, we should be looking at how to move out into Spring as a Service or Provider attached to a service. Then work on cleaning up the properties so there less of the current property value parsing format and key number enumeration nightmares happening and the properties are more "normalized". > Absolutely, the sysadmin. is allowed to break anything, so long as he > is prepared to answer for it. :-) I expect that (both aspects) when I > wear my sysadmin. hat. I agree, Mark Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
