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
