commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mingfai Ma" <ming...@hongkong.com>
Subject RE: [Configuration/Digester] best practice of loading configuration
Date Thu, 13 Feb 2003 07:06:51 GMT
thank for Craig and Vilmantas' detailed reply.

Indeed, it was in my mind to ask a follow-up question about how do ppl
design
configuration in a pattern similar to DAO, i.e. the configuration data may
be
stored in different place, e.g. properties files, xml files, ldap directory,
db
etc. Well, it seems to be a case of "over-design".

So, configuration 'design' should be broken down into two/three parts, I
summarize the ideas with some comments as follows:

1. storing the configuration
	>where you get your configuration properties from
	- in property files, xml files etc.
	- Vilmantas suggested a smart 'pattern' to provide flexible locating and
	  extension of configuration files in multiple formats.

	- btw, some ppl suggest to store in LDAP. one of the benefits is the
	  distributed nature. IMHO, any need for distributed configuration
	  should be handled by JMX instead.

2. reading the configuration
	>(and how they are read)
	- Other than the standard java.util.Properties, two Apache projects,
	  Commons Configuration and Digester are available to read the properties.
	- The loaded properties should be stored in 'proxy objects', but not
	  directly make use by the application.
	- the 'proxy' could/should be as JavaBeans. Digester provides a mechanism
	  to store the proxy objects in a stack. (read xml, set properties etc.)

	- IMHO, BeanUtils DynaBean could be as 'proxy' used to make it more
	  flexible. Collection or JavaBean in Composite Pattern are other options.

3. using the configuration
	>what you do with them
	- To be done programmatically (for sure!)

	- IMHO, if the application is with enough scale, the properties should be
	  set to MBeans. And the application programmatically read configurations
	  from the MBeans.
	- I am looking for a way to make it easy to set the values to MBeans. As
	  far as I know, BeanUtils is the best choice.

There are some cases that need to be handled specifically:

1. 	store and read properties that are defined from 0 to n times.(not 1
time)
	-> handle by Digester

2. 	read and use properties in condition
   	e.g. 	data source can be defined either in JNDI path (to a DataSource)
or
	  	JDBC driver name, url etc.
	-> do programmatically in a polymorphism way

3. 	dynamic loading
	it's no longer talking about loading 'static' configuration. But an
	implementation of a mechanism to monitor any changes in the conf.

4. 	persistence of configuration
	There is project called JPos in Sourceforge that implemented a
	microkernel in JMX called Q2 that does this. Configuration can be updated
	in runtime and the updaets are made persistent to the configuration file.

Any comments? and other ideas? I wonder how frameworks and mature products
like
Avalon or Tomcat does their configuration.

fyi, I am researching and learning the best-of-the-breed way to do
architectual
design. A JMX-based microkernel is the core, and loading configuration is
one of
core component.

Regards,
mingfai


> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Thursday, February 13, 2003 1:26 AM
> To: Jakarta Commons Users List
> Subject: Re: [Configuration/Digester] best practice of loading
> configuration
>
>
>
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>


Mime
View raw message