This discussion is archived
3 Replies Latest reply: Feb 2, 2012 3:50 PM by jschellSomeoneStoleMyAlias RSS

Design suggestion for application-wide configuration properties

912776 Newbie
Currently Being Moderated
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
  • 1. Re: Design suggestion for application-wide configuration properties
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    909773 wrote:
    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.
    Presumably that is a realistic goal and one which is actually needed.

    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.
    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.
    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 them
  • 2. Re: Design suggestion for application-wide configuration properties
    912776 Newbie
    Currently Being Moderated
    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 them
    As 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. I am not talking about manual changes to a configuration file. 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).

    However, my question is about the easy part and, more specifically, about whether having code like

    PropertyManager.getProperty("<some_key>");

    or even

    PropertyManager.getThatProperty();
    PropertyManager.getTheOtherProperty();

    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.
  • 3. Re: Design suggestion for application-wide configuration properties
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    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 them
    As 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.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points