On Tue, Jun 28, 2011 at 11:44 AM, Richard Rodgers <[email protected]> wrote:
> Hi Robin:
>
> I cobbled together a few notes on modular configuration in
> ConfigurationManager, which might inform your work....
> (I'm not an expert on ConfigurationService, so others can chime in)
>
> The changes made to support modular configuration were intended to be
> completely backward compatible, so the family of methods that are *not*
> modular, eg,
>
> ConfigurationManager.getProperty("foo.bar")
>
> will attempt to retrieve a property in dspace.cfg named 'foo.bar', which is
> exactly what they used to do.
>
> There are a *new* set of companion methods that are 'modular' :
>
> ConfigurationManager.getProperty("foo", "bar")
>
And likewise, for the record, if you port to the ConfigurationService it
would be
new DSpace().getConfigurationService().getProperty("foo.bar"); prefixing is
managed in parsing the key, not in an additional parameter in the method
signature. Likewise all the details below apply to the configuration service
as well.
>
> where 'foo' is the module and 'bar' the property name.
> Calling this method will result in the following steps:
>
> (1) Is there a memory-resident configuration map (set of properties) named
> 'foo'?
> If so, return the value (if any) of the 'bar', property, else
>
> (2) Is there a file /dspace/config/modules/foo.cfg?
> If so, load it into memory, filter occurrences of ${x} from the
> 'master' properties in dspace.cfg then follow step (1), else
>
> (3) is there a 'foo.bar' property in dspace.cfg? If so, return it.
>
> This third step was intended to make it flexible to 'move' properties in
> and (mostly) out of dspace.cfg. As long as you code using the modular
> methods, it doesn't matter whether the properties live in modules or
> dspace.cfg, and in fact you can move them from one location to the other
> without recoding, *provided* you follow the convention that is implied by
> this, namely:
>
> if a set of properties all have a common prefix in dspace.cfg, that prefix
> becomes the name of the file in modules. So, e.g.
>
> sword.property1=…
> sword.property2=/..
>
> becomes /modules/sword.cfg with values:
>
> property1=…
> property2=…
>
> To reverse the process ('promote' properties into dspace.cfg), just prepend
> all the properties with the name of the config file
> ('sword'), and drop into dspace.cfg
>
> The second step deliberately lazy-loads the module properties, so that if
> you are running, say, a simple command-line tool,
> only dspace.cfg and the config files of interest are loaded: this makes
> config files quite scalable and efficient.
>
> Apologies for not providing a clearer explanation earlier….
>
> Richard
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> 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
Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
