Comments from someone who doesn't program much (anymore, save 370 Assembler on 
an IBM Mainframe!)

Finally!  I understand all of this from Mark Diggory and Mark Wood has made it 
much easier by asking the questions I 
had without sounding like a dummy.

The dialogue of the message below needs to be codified into some type of FAQ 
that would assist many of the people 
"in the trenches" with the question "what does this mean for me?" and "How will 
I be affected".

It seems, correct me if I'm wrong, this should make the dspace.cfg and other 
cfg files go away in favor of a database approach
for all configuration, including the need to get away from command line running 
of ant update, correct?  (Or at least it could
run in the background).

Does this also mean that mean of the configurations and services we have in 
DSpace can be accessed via the web instead of
at the CLI?  If so, all the more to say "Go for it Mark(s)".

Please educate me if I'm totally off the trodden path, otherwise, you've got 
one more fan for DSpace Services.

--Jeff

On Mar 3, 2011, at 11:15 AM, Mark Diggory wrote:

> 
> 
> On Thu, Mar 3, 2011 at 7:39 AM, Mark H. Wood <[email protected]> wrote:
> Thank you.  It seems a good example of how *and why* to think about
> this stuff in a context where everything you need to know is supplied
> from outside, rather than going to find it out yourself.  I think one
> problem we've had is that a concise exposition on the *why* was
> missing:  what does all this work buy us?
> 
> Briefly, it buys us a consistent means of configuring the application that is 
> not as "custom" and "limited" as PluginManager is, the DSpace Services are 
> like ConfigurationManager and PluginManager on steroids. Much more flexible 
> and with no need to worry about parsing Configuration properties or 
> introducing strange property evaluations into your code.  
> 
> In my next article I will try to show an example of why PluginManager still 
> deadlocks our domain models to parsing a configuration file (dspace.cfg) by 
> hand and then writing our own reflective code to create something that Spring 
> provides standard off the shelf.
> 
> 
> Some readers are going to spot a point of confusion and ask: why do we
> want to start up the Configuration Service if we're going to be
> configured by Spring?  Why do we even *have* a Configuration Service?
> I dunno.  This needs explanation.
> 
> No ConfigurationService is started separately, ConfigurationService is in the 
> Spring Context and available to lookup. The reason ServiceManager/Kernel are 
> started in the Launcher main code is because, unlike the webapplications 
> which bootstrap the environment themselves, in the ScriptLauncher, something 
> needed to do that bootstrap for us.  Anyone actually writing commands or 
> services shouldn't need to bother with this bootstrapping.
> 
>  
> 
> Some readers will not be familiar with Spring, so a pointer off to a
> good, compact document on Spring configuration elements and their use
> would be welcome.  I poked around a bit at springsource.com but didn't
> find anything I thought suitable.
> 
> Not to be "smart" but there are plenty of tutorial materials on the web for 
> spring.
> 
> http://google.com?q=%22Spring+Framework+tutorial%22
> 
> Which is another point in favor of the approach, you do not see 34K of 
> results when you search for "DSpace PluginManager Tutorial"
> 
>  
> Somewhere, not necessarily in this article, we need a fairly extensive
> discussion of how we want to structure configuration of the product.
> We have multiple configuration sources:  Spring properties, the
> Configuration Service (and the place(s) from which it gets external
> configuration data), the Servlet container (for the bits that are
> webapp.s).  We have multiple configuration consumers:  commandline
> app.s, webapps, and the build process.  We need some exposition on
> when to use a particular source, and why.  I expect this will require
> some debate among developers to reach a consensus.
> 
> Ironically, almost all of the configuration is devided into two parts (a) 
> Application Configuration driven by Spring and (b) Preferences driven by the 
> ConfigurationService,  all the configuration service is doing at the moment 
> is loading the same environment as ConfigurationManager, in fact, we just 
> enhanced the next version to support the config/modules directory that 
> Richard added so that we continue to maintain party between the two 
> approaches.
> 
> Once fully integrated, we are proposing that ConfigurationManager and 
> PluginManager be deprecated and replaced by ConfigurationService and 
> ServiceManager.  Which are details we have been developing in the the 
> "Proposals" section of the wiki.
> 
> https://wiki.duraspace.org/display/DSPACE/Replace+DSpace+ConfigurationManager+and+PluginManager
> 
> thanks MarkW, all good points to extrapolate on.
> 
> Mark
> -- 
> Mark R. Diggory
> @mire - www.atmire.com
> 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
> Technologielaan 9 - 3001 Heverlee - Belgium
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel

Jeffrey Trimble
System LIbrarian
William F.  Maag Library
Youngstown State University
330.941.2483 (Office)
[email protected]
http://www.maag.ysu.edu
http://digital.maag.ysu.edu
""For he is the Kwisatz Haderach..."

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to