On May 17, 2010, at 9: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?
Yes, ideally, I am recommending adopting the use of DSpace services over the default Managers for new development wherever possible. There was a small bug that limited it form working in dspace 1.6.0, this has been corrected for the Dpace 1.6.1 release. > >>> >>> 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. Well, that is where the rubber meets the road isn't it... Aaron, Graham, Brad, Ben and I placed a great deal of work into creating the thing last year, the materials could stand some consolidation and community members are welcome to join in to assist in getting documentation and understanding to the next step. Where the official documentation will one day live... http://wiki.dspace.org/confluence/display/DSTEST/DSpace+Services+Framework Where the current resources are today... http://wiki.dspace.org/confluence/display/DSPACE/DSpace+Services+Framework http://www.slideshare.net/mdiggory/dsug09-services-2255693 http://wiki.dspace.org/confluence/display/DSPACE/DSpace+2.0#DSpace2.0-CurrentDevelopment http://wiki.dspace.org/confluence/display/DSPACE/DSpace+2.0+Modelling+Services http://wiki.dspace.org/confluence/display/DSPACE/DSpace+2.0+Core+Services > > I think the question of runtime reconfiguration, yes or no, is a > separate one. Both deserve discussion time. Yes it certainly is, but it would be silly to implement runtime config on a subsystem we are attempting to deprecate and do away with. > >>> 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. All J2EE containers have to provide a JNDI context where JNDI resources such as database connection pools can be configured. In JEE, such JNDI resources are generally served out to the webapps by the EAR+WAR installed into the server. The topic is relevant and has been discussed in the past, however, we are currently stuck with CLI needing to have the config as well, leaving us the need to configure it in two different places. Perhapse allowing such a violation DRY would actually be enabling and simplifying for the architecture. Eventually, I think many would prefer to see the CLI fade away in favor of a webapp driven job engine... something like the Quartz Scheduler I quickly hacked... > >> 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. What most people do not realize is that Spring has been our direction since DSpace 1.5.2 when we upgraded the XMLUI to use Cocoon 2.2. The DSpace 2.0 work was almost entirely Spring centric, though with a consideration that other IoC/DI solutions and frameworks may become of interest tot he community. > 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. What Spring gives int he area of PluginManager configuration / support is a generic configuration capability that reduces the presence of "property parsing hacks" in the code, eliminating these hacks lightens the code and allows it to be more easily extended. I.E. add a Property to a Bean and you have a value you can configure in your properties, no further logic required. What we will need to see is greater embracing of Spring and training on how to configure the applications using it. Thats a project folk's like myself are will ing to take on, but theres a great deal of preparation that still needs to happen to be informative about it. 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
