On Tue, May 18, 2010 at 04:48:47PM -0700, mdiggory@... wrote:
> On May 17, 2010, at 9:23 AM, Mark H. Wood wrote:
> > On Fri, May 14, 2010 at 01:57:45PM -0700, mdiggory@... 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 mwood@...
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_