Design suggestion for application-wide configuration properties

Question

Hello all
I am seeking opinions on how to design an application in which multiple classes have access to a common set of configuration properties that may change at runtime.
Until now, I would create an abstract class dedicated to initializing the properties set and enabling access to them from anywhere in the application through appropriate get/set static methods (most probably using an internal java.util.Properties object). Lately, my confidence in that approach seems to diminish.
So, I thought I should ask... do you see any issues with the above approach? Would you suggest any alternatives?
What I am essentially looking for here is a best practice to stick with from now on.
Thanks in advance
G

Answer 1

909773 wrote:
For example a 24x7 service that is supposed to handle requests on port X is very unlikely to need to change to port Y while running.
Or what happens if you have a plugin architecture and someone changes the root plugin directory to another directory.On the other hand, the maximum draw distance in a virtual world, an application's "skin", or a filesharing client's bandwidth limit are, in my view, properties that may very well need to change at runtime.
Seems reasonable to me. That is the easy part. The hard part is
1. How/when do you reload
2. How do you code your app so it gets the new values and uses themAs for 1, apologies if I haven't explained correctly: I am talking about properties that may change programmatically at runtime, e.g., by a user through a configuration dialog. Ok.
I can think of at least one way to deal with 2 (classes interested in all or a few of the properties implement some property listener interface and accordingly re-get values when notified about changes).That is how you detect it. It has nothing to do with whether the current running process is in a state that allows changes to be made.
all over the code reflects a wise design decision vs using a singleton property manager, references to a single property manager object (maybe even a java.util.Properties object) passed around through constructors, approaches involving dependency injection (not relying on any framework though), or else.Depends on the application. For example with a distributed system propogating the changes correctly so systems are not out of sync can be problematic.
Depends on the context in which your user makes changes. If it is an admin then it has the same context has if you were using a file. In that case I would use a singleton.
If it is a user changing part of the system, then you can't use a singleton. In that case you would need a context object from which other code derives the configuration values it uses. That is a one layer hierarchy and of course more levels require more complexity via a context object for each level.