On 28 June 2011 21:40, Mark Diggory <[email protected]> wrote:
> On Tue, Jun 28, 2011 at 11:44 AM, Richard Rodgers <[email protected]>
> wrote:
>
> 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.
>
>
I realise it's a bit late for this, but really what I would much rather see
is:
a) New style ConfigurationService should be injected by Spring, not
retrieved from a method call (either static or from a new Object).
b) Accessing a configuration for a 'module' should be distinct in itself.
eg:
ConfigurationManager.getConfigrationFor("foo").getProperty("bar")
or
new
DSpace().getConfigurationService().getConfigurationFor("foo").getProperty("bar")
G
------------------------------------------------------------------------------
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
