All, For now, I've added this Runtime Reconfiguration topic to the list of Special Topics & linked back to this email thread (so feel free to continue discussion here).
As Mark W. had mentioned, we should discuss whether Runtime Reconfiguration is a goal of DSpace Roadmap. It would be worth verifying that we are all on the same page -- I'll see if we have time to discuss that proposed goal in this week's Developers Meeting (assuming we don't need the full time for 1.6.1-oriented discussions). http://wiki.dspace.org/confluence/display/DSPACE/Special+Topics#SpecialTopics-RuntimeReconfiguration%2FDSpaceServices I agree, more discussion on DSpace Services would also be nice. Perhaps we could get Mark Diggory to lead some discussion/basic overview in a future Special Topic Meeting (maybe even next week, May 26)? Would you be willing, Mark D? Hopefully this can help get the "buy-in" for more -services support for 1.7.0 and beyond. - Tim On 5/17/2010 11:23 AM, Mark H. Wood wrote: > On Fri, May 14, 2010 at 01:57:45PM -0700, mdigg...@atmire.com wrote: >> >> 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. > > Is that something we're supposed to be using now, then? > >>> >>> 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. > > I'd like to see some discussion of what dspace-services *are* and what > we need to be doing about them. > > I think the question of runtime reconfiguration, yes or no, is a > separate one. Both deserve discussion time. > >>> 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). > > Besides being a chicken/egg problem. :-) > > I've been thinking for some time that I ought to see whether it makes > any sense to provide the database linkage through the servlet > container. > > [goes to see] > > Things like environment entries and resource references seem to be > optional parts of the servlet spec. Tomcat provides them but other > non-J2EE containers may not. Drat. But database URLs and credentials > could be made webapp context parameters. > >> 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". > > Is Spring our direction now? Sensible, and I've begun using it where > it doesn't impact established practice, but I wasn't aware that > established practice is to be changed. > > I agree that there are areas of the current configuration that > strongly resist being squashed into Properties format and should > change *somehow*. I'll have to study a bit, though, to imagine ways > they could be done in Spring other than maps-within-maps, which is > largely the same mess only wordier. > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
