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.
pgpDTPxaMIvQP.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
