commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [Configuration/Digester] best practice of loading configuration
Date Wed, 12 Feb 2003 17:25:43 GMT


On Wed, 12 Feb 2003, Vilmantas Baranauskas wrote:

> Date: Wed, 12 Feb 2003 17:13:44 +0100
> From: Vilmantas Baranauskas <vilmantas.baranauskas@danet.de>
> Reply-To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> 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

Mime
View raw message