On Tue, May 18, 2010 at 04:48:47PM -0700, [email protected] wrote: > > On May 17, 2010, at 9:23 AM, Mark H. Wood wrote: > > > On Fri, May 14, 2010 at 01:57:45PM -0700, [email protected] 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.
I give your recommendations considerable weight. But there is a difference between "I recommend" and "we all decided to start doing this." I hope that this week's special-topic meeting will move us toward a decision. > >> 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. As a beginning, mostly to help myself begin to get my arms around Services, I've been hacking away at the Javadoc thereof. I don't claim to understand much of it yet, but I find the result more readable and the exercise did drag me through all of the code, which should help. Anyone who *does* understand Services is invited to correct my errors and omissions. > > 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. If most people do not realize it, then it hasn't been "our" direction; it has been some folks' direction. IMHO probably a good direction. But, as with Services, we need a decision: are we all going to start doing this now? [Spring gives us good things] > 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. Starting with the consensus. Probably that means a decision to make fuller use of Spring (in some fashion) happen in 1.7. You made a good point above which I had not sufficiently remarked: not only do we need to decide what configurations go in the database (if we're going to do that), but which ones belong in a Spring application context. I think we might classify things thus: o Operational controls o Deployment settings o Runtime assembly of the instance I think those are arranged in order from "most likely belong in the database" to "most likely belong in the application context". But that's just a sketch, and needs more thought. -- Mark H. Wood, Lead System Programmer [email protected] 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_
pgpKQFahhKNlQ.pgp
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
