On Wed, 12 Feb 2003, Vilmantas Baranauskas wrote:
> Date: Wed, 12 Feb 2003 17:13:44 +0100 > From: Vilmantas Baranauskas <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Users List <[EMAIL PROTECTED]> > To: Jakarta Commons Users List <[EMAIL PROTECTED]> > Subject: Re: [Configuration/Digester] best practice of loading > configuration > > Hi, > > Mingfai Ma wrote: > > how do you design your system to load static configuration? ... > > I do it like this. > There is a configuration subsystem. It has one main configuration file > "application.properties" which is located in classpath. Then there is > java class (Configuration) which has static access so application can > access it from everywhere and doesn't need to perform any instantiation > because Configuration class can load "application.properties" from the > classpath. > One configuration design pattern that I prefer is to separate the notions of where you get your configuration properties from (and how they are read), versus what you do with them. For the latter scenario, it is easy to "configure" a JavaBean by simply calling the appropriate property setters on it. That way, this JavaBean can be used in different environments, and be configured in different ways. Digester itself is both an example of this, and has some built-in rules that make it pretty easy to implement the pattern. A Digester instance is fundamentally configured by calling property setters and addXxxx() methods -- which can in turn be done by direct programming calls or by reading an XML configuration file. And, if you use the SetPropertiesRule, you can add new configurable properties on your beans without having to change the Digester setup -- it automatically matches the attributes of an element to the JavaBean properties of the top object on the evaluation stack. But the basic idea is that I like separating what you're configuring from how you configure it. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
