I haven't thought about the details of accessing properties in a singleton yet.
In the first line I was interested in the advantages such an approach would have for initialization of the configuration framework. On its creation the singleton instance could locate the configuration description file by some criteria (to be defined, e.g. by the searching the class path), set up a ConfigurationFactory and then load all specified configuration sources. This would be a great help for developers.
I had a look at the code you pointed out, but because I don't know anything about Avalon and Turbine I don't fully understand what's going on there. But I think the configure() method of DefaultConfigurationService performs some tasks that would have to be done by our singleton, too. Am I right?
To come back to thread safety once more: In my opionion it is important that the configuration classes guarantee to be thread-safe in read only accesses. Well, I am quite sure that this is already the case, but it would be certainly a good idea to make a corresponding note somewhere in the documentation.
Oli
Eric Pugh wrote:
Good reply Oliver. Are you thinking of some sort of SingletonConfiguration object that just has a single static Configuration object.. So, whether you call it as SingletonCongifuration.getString("test.value") or create an object singletonConfiguration.getString() you get the same thing?
Something to look at is an Avalon wrapper I tossed out in Fulcrum[1]. This provides a "singleton" in terms of the Container being responsible for returning just one instance of the object, verus loading multiple. It seems to me that as long as we are talking readonly, then it doesn't matter how many threads read, correct? And, if you want to write, just toss a sychronize keyword?
Eric
[1]
http://jakarta.apache.org/turbine/fulcrum/fulcrum-configuration/index.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
