In an effort to better accommodate the assorted bean centric configuration and dependency wiring frameworks (e.g. Spring, MC) I'm considering further changes to the way TS internals are configured. Currently we have a property management system based on a per module Environment class (a set of named constant Strings), paired with a per module PropertyManager (which is basically a java.util.Properties). The normal usage idiom for retrieving config is something like String theValue = mymodulePropertyManager.getPropertyManager().getProperty(mymodule.Environment.SOME_KEY); The drawbacks of this are a) it's not type safe - theValue may need munging to a particular type, a somewhat laborious process that's repeated all over the codebase and b) the PropertyManager does not know about default values - applying one is up to the consuming code, which means they are spread all over the place as I discovered whilst trying to update the manuals. What I'd like to do is introduce a per-module EnvironmentBean, which will simply have typesafe getters and setters for any property currently defined in the corresponding Environment class. A singleton instance of this will be created and populated by walking the properties file and calling setters accordingly. Anything not set will have a default value declared in the EnvironmentBean, making it easy to find these. Injection frameworks can retrieve this singleton and apply their own config by making additional setter calls. Usage will therefore become of the form MyType theValue = mymodulePropertyManager.getEnvironmentBean().getMyValue(); and the type conversion and default handling code will vanish from the point of consumption. This will also reduce the desire to do this property retrieval in static blocks, as there will no longer be any significant hassle or performance overhead to retrieving it from the manager on each use. However, actually relocating the retrieval code will need careful thought - in some cases all hell will break loose if a value is changed whilst the system is running. Maybe the javabeans validation/veto mechanism or similar can eventually be used to disallow changes when the system is in certain states. Meanwhile we are no worse off than currently, as System.setProperty carries equivalent risks at present. Thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245824#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...