On Tue, Jun 28, 2011 at 2:50 PM, Graham Triggs <grahamtriggs@gmail.com> wrote:
On 28 June 2011 21:40, Mark Diggory <mdiggory@atmire.com> wrote:
On Tue, Jun 28, 2011 at 11:44 AM, Richard Rodgers <rrodgers@mit.edu> 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,


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:

new DSpace().getConfigurationService().getConfigurationFor("foo").getProperty("bar")


Graham,  I'm working towards this as we discussed at OR11 (for the WebMVC/XMLUI  webapplicationcontexts as well as the servicemanager)  also, the Spring application context has all the properties assigned in it via the placeholder, so annotation driven config will be possible and you will not even need to reference ConfigurationManager or ConfigurationService to inject configuration into your Classes... they will just be bean properties.


Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium