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.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Balance your desire for bells and whistles with the reality that only a
little more than 2 percent of world population has broadband.
-- Ledford and Tyler, _Google Analytics 2.0_
pgptCHBhEW7yJ.pgp
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
