MarkW, Now I think we need to be careful about misinformation.
1.) ServiceManager is not OSGI, so we cannot do reconfiguration of services on the fly. we would need to expose the dspace-spring-xxxx.xml files in a cetral location if you wanted to alter those without rebuilding your dspace. 2.) DSpaceConfigurationService is currently the only configuration service, and is instantiated outside Spring. Its a chicken or egg issue. ConfigurationService tells the ServiceManager where to get details prior to initialization of the Spring ApplicationContext. 3.) Right about Spring xml's representing arbitrarily complex application structure and not easily being stuffed into a database table. We need to clarify a separation between "Application Configuration" via Spring vs. "Application Preferences" via a cfg file or database table. For instance, considering the current PluginManager. The classes for the plugin getting configured is "Application Configuration" but the individual properties that each of those plugins might like to use... thats "Application Preferences"... Preferences should be changable, possibly even at runtime, and available via the ConfigurationService. "Application Configuration" we delegate to Spring and would require a restart of the server to make available. The best example I can think of that captures this is, I download a "jar" that represents my addon and place it into my lib directory, the application needs to be restarted to get it onto the classpath where it can be detected. OSGi is a container that allows you to do this without restarting... but thats a much larger beast to get our project entangled with... Spring is a stepping stone to even begin thinking about using OSGi. You'll find that the Fedora and DuraCloud developers are already advanced beyond us in this area and represent the expertise we need to continue the evolution. So, we needed the Fedora team as much as they need us and the DSpace community at large. Theres a very important developer synergy emerging there. Mark On Thu, Mar 3, 2011 at 11:46 AM, Mark H. Wood <[email protected]> wrote: > On Thu, Mar 03, 2011 at 01:22:21PM -0500, Jeffrey Trimble wrote: > > 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). > > That's one thing we could do. But then, we could have > ConfigurationManager consult database tables too. There are several > things going on here. > > o ConfigurationService (*or* ConfigurationManager) hides the way we > store configuration data. Right now they both read in one or more > Properties files. Clients of either just present a name and get > back a value. The mapping could be stored in a DBMS table as > readily as a flat text file. > > Well, most of it. We still need enough configuration to identify > and connect to the database, before we can look in the database for > answers. The webapp.s could be supplied this with a small number > of context parameters or JNDI resources or both. Commandline app.s > would still need a bootstrap configuration file or some such. > > o ServiceManager makes hunks of infrastructure replaceable without > rebuilding DSpace. If you want to know how to get configuration > data, for example, you ask the ServiceManager for the thing which > offers that service, and then use the thing. The idea seems to be > that what we currently call Plugins would become Services. But in > addition quite a lot more of DSpace becomes pluggable. You can, > for example, tell ServiceManager at runtime to switch to a > different ConfigurationService (if you can think of a reason to do > so) and all subsequent configuration queries will use the new one. > > More interesting to me is that you can just drop additional JARs > into [DSpace]/lib or anywhere else on the CLASSPATH and tell > ServiceManager to use code from them, without rebuilding. You can > add new services by drop-in. If the configuration data are fetched > from similarly separable storage (multiple files or whatever, > recently implemented) then you don't have to disturb *any* part of > a working installation in order to extend it or replace bits of it > with (from the code's point of view) functional equivalents. > > o One of the things Spring brings to the table is a nice set of > PropertyEditors which let you express complex objects in a standard > way. If a configuration value really needs to be a list of > strings, for example, you don't need to write "alpha, beta, gamma" > or "alpha beta gamma" or whatever and then have to parse that to > find out what is inside. Spring specifies how you write list > values and presents them to the code already cracked into > individual data in a List. The individual data don't have to be > Strings anymore either; you can be delivered integers or object > references or pretty much whatever your code wants to work with. > > There are a number of configuration values which are really Lists > or Maps or even stranger things, but we can't write them that way > in the configuration; we have to invent ways to express them as > plain Strings. Different people have done the same thing > differently, and there are places where we see that sometimes we > are not totally focused on producing robust parsers for the > configuration sublanguages that we create. Some of the things > people have had to do in order to force structured values into > Properties format are hard to read and easy to mistype. > > Spring is usually configured from one or more XML documents. Since > there's the potential to represent arbitrarily complex data > structures, this argues *against* tabular (database) storage. We > could provide helpful UI and store the values in XML behind the > scenes, though. XML is human-usable but not human-friendly. > > If Spring can see that a number is wanted and the value is "abc", > it will tell you that you goofed before DSpace ever starts. > > You touch on an important (separate) point: installation is too > involved with operational configuration values, and we are too > dependent on the installation process for subsequent operational > adjustments. ("ant update") > > > 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)". > > Not until someone writes that part. What's needed before we can do > that is to ensure that every user of configuration data always uses > the current settings. In any given user you either fetch the value > you want every time you need it, or you need a way to know when > interesting values have changed so you can refresh them. > ConfigurationManager wasn't designed to support the latter; IIRC > ConfigurationService and EventService were. > > Treating configuration data as changeable at runtime requires > inspecting and in many cases altering *every piece of code which is > configurable*. This won't happen quickly. You'll probably see a few > pieces of low-hanging fruit done first and then a slow spreading of > the idea throughout the product over a number of releases. > > -- > Mark H. Wood, Lead System Programmer [email protected] > Asking whether markets are efficient is like asking whether people are > smart. > > > ------------------------------------------------------------------------------ > 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 > > -- 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
