Daan, Yeah... I would have preferred to use the first constructor only just because it makes more sense. The problem is the second constructor saved me a lot of typing when I convert from the enums in Config.java to using this class. So I kept both in there. I think as long as it's no ambiguous, it should be okay. If we want to make sure, we probably should remove the first constructor. The number of things I have to type for the first one was just prohibitive. :P
As for the multiplier, I figure its usage is probably too small to deserve another constructor. If there's a need for it, please go ahead and add another constructor. --Alex > -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: Monday, September 9, 2013 12:01 PM > To: dev > Subject: Re: Configuration variable changes... > > Alex, > > I looked up the constructors and figured it out. next question is about two of > them: > > public ConfigKey(Class<T> type, String name, String category, String > defaultValue, String description, boolean isDynamic); and > public ConfigKey(String category, Class<T> type, String name, String > defaultValue, String description, boolean isDynamic); > > should one of them be removed? > > makes more sense to add a > public ConfigKey(Class<T> type, String name, String category, String > defaultValue, String description, boolean isDynamic, T multiplier); that uses > global scope. > > > > On Mon, Sep 9, 2013 at 7:48 PM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > Looks great Alex, > > > > One question; Adding a scope or a multiplier is featured on the wiki > > but not specified. Can you add a pointer to it? > > > > Very nice indeed, > > Daan > > > > On Mon, Sep 9, 2013 at 7:20 PM, Alex Huang <alex.hu...@citrix.com> > wrote: > >> As part of the work to pull apart orchestration from self service, I made > some changes to how configuration parameters work. The problem with the > current system are as follows: > >> > >> - configuration variables are all stored as enums in Config.java which > means plugins have to modify a single file. We established that to be a bad > pattern in some earlier thread. > >> - No way to tell during upgrades whether a config variable has become > useless or if the defaults have changed. > >> - No way to consistently have variables be dynamically updated. > >> - No way to consistently migrate a global variable to a scoped variable. > >> - No way to use more than one type of storage (db) to store config > variables. > >> - Some of the code are still using text strings to retrieve configuration. > >> - No way to consistently validate variables. (although this is not > >> done yet but I described how it can be done in this new framework.) > >> > >> The changes are detailed on wiki [1]. There's a detail list of todo items > >> in > ConfigDepotImpl.java if you're interested in picking up any of the work. The > old way still works but I recommend we move all new way for new config > parameters. > >> > >> If everyone reviewed it all and like how it works then we can remove the > old way of how it all works. > >> > >> --Alex > >> [1] > >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
