You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Mingfai Ma <mi...@hongkong.com> on 2003/02/12 16:13:56 UTC
[Configuration/Digester] best practice of loading configuration
how do you design your system to load static configuration? there are a few
ways as I know:
1. Properties.load() or Commons-Configuration
- the configurations are stored in properties file and is loaded to a
Properties for further processing
- it's the traditional way
- the Commons Configuration provides additional benefit as it allow
repeated value-pair
(as far as i know, the XML Configuration has nothing, so, i don't include
it)
2. Digester
- configurations are stored in xml file, and is processed sequentially by
rules.
- i used Digestor in one of my project last year. i think Digester is
powerful. but as my configuration was changed a couple of times, it turns
out I have to maintain the Digester rules which are quite clumsy.
3. JAXB / XML-to-Object mapping
- i think it's not a common way, but technically possible. just map the
configuration xml to an object and process further.
- but... it seems to be more "clean" in design
are there other common ways? what is the best practice to load static
configuration? and how about loading to a MBean? I wonder the ways can be
compared by maintainability, easy of development, easy of learning etc.
Regards,
mingfai
RE: [Configuration/Digester] best practice of loading configuration
Posted by Henri Yandell <ba...@generationjava.com>.
My plan is to _always_ use JNDI for configuration, I think it's the best
solution.
http://www.generationjava.com/docs/simple-jndi/
is a JNDI implementation on top of .properties in a file structure. Next
steps are:
1) Allow .properties files to be accessed via http, file and classpath.
2) Allow an xml format to be used instead.
So rather than trying to hide JNDI behind some other solution, I'm just
aiming to make JNDI available everywhere.
Hen
On Thu, 13 Feb 2003, Mingfai Ma wrote:
> 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 <vi...@danet.de>
> > > Reply-To: Jakarta Commons Users List <co...@jakarta.apache.org>
> > > To: Jakarta Commons Users List <co...@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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
RE: [Configuration/Digester] best practice of loading configuration
Posted by Mingfai Ma <mi...@hongkong.com>.
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 <vi...@danet.de>
> > Reply-To: Jakarta Commons Users List <co...@jakarta.apache.org>
> > To: Jakarta Commons Users List <co...@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
>
Re: [Configuration/Digester] best practice of loading configuration
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 12 Feb 2003, Vilmantas Baranauskas wrote:
> Date: Wed, 12 Feb 2003 17:13:44 +0100
> From: Vilmantas Baranauskas <vi...@danet.de>
> Reply-To: Jakarta Commons Users List <co...@jakarta.apache.org>
> To: Jakarta Commons Users List <co...@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
Re: [Configuration/Digester] best practice of loading configuration
Posted by Vilmantas Baranauskas <vi...@danet.de>.
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.
So, when I have "application.properties" like this:
prop1=value1
prop2=value2
then I access these properties by invoking:
[Prefix]Properties props = Configuration.getProperties();
props.getProperty("prop1");
There is pluggable system to extend properties. If I need properties to
be loaded from other source then I add special configuration properties
to "application.properties":
configuration.loader.props1=org.xxx.FilePropertyLoader
configuration.loader.props1.file=my.properties
configuration.loader.props2=org.xxx.FilePropertyLoader
configuration.loader.props2.file=another.properties
configuration.loader.props2.prefix=my_prefix.
configuration.loader.props3=org.xxx.XmlPropertyLoader
configuration.loader.props3.file=some_more.xml
configuration.loader.props3.prefix=this_comes_from_xml.
Now properties from three files "my.properties", "another.properties"
and "some_more.xml" are loaded and available from
Configuration.getProperties(). Properties from "my.properties" file are
available directly and properties from "another.properties" are
available under prefix "my_prefix.".
PrefixProperties class has a method getPrefixedProperties(String
prefix):PrefixProperties so you can easily retrieve properties under prefix:
Configuration.getProperties().getPrefixedProperties("my_prefix.");
One thing which I miss in jakarta-commons-configuration is that it has
no static access to it.
Regards
Vilmantas
--
Vilmantas Baranauskas
Phone: +49-711/13353-47 FAX: +49-711/1335353
D A N E T - IS GmbH, Waldburgstrasse 17 - 19, D-70563 Stuttgart
Email: vilmantas.baranauskas@danet.de
RE: [Configuration/Digester] best practice of loading configuration
Posted by Henri Yandell <ba...@generationjava.com>.
It's not a biggy. The first time you sent it without being subscribed to
the list. Rather than bouncing the email, the email is sent to four people
[of whom I am one] who moderate it to decide if it should be sent on to
the list or refused.
So the first email went through with a bit of delay while I gave it the
thumbs up to carry on.
Sorry for the confusion,
Hen
On Wed, 12 Feb 2003, Mingfai Ma wrote:
> I'm terribly sorry that this message goes to the list for three times. I
> sent it once, and thought it was not delivered, and sent it for the 2nd
> times with a slight change in the subject.
>
> sorry for any inconvenience.
>
> regards,
> mingfai
>
> > -----Original Message-----
> > From: Mingfai Ma [mailto:mingfai@hongkong.com]
> > Sent: Wednesday, February 12, 2003 11:14 PM
> > To: commons-user@jakarta.apache.org
> > Subject: [Configuration/Digester] best practice of loading configuration
> >
> >
> > how do you design your system to load static configuration? there
> > are a few
> > ways as I know:
> >
> > 1. Properties.load() or Commons-Configuration
> > - the configurations are stored in properties file and is
> > loaded to a
> > Properties for further processing
> > - it's the traditional way
> > - the Commons Configuration provides additional benefit as it allow
> > repeated value-pair
> > (as far as i know, the XML Configuration has
> > nothing, so, i don't include
> > it)
> >
> > 2. Digester
> > - configurations are stored in xml file, and is processed
> > sequentially by
> > rules.
> > - i used Digestor in one of my project last year. i think
> > Digester is
> > powerful. but as my configuration was changed a couple of times, it turns
> > out I have to maintain the Digester rules which are quite clumsy.
> >
> > 3. JAXB / XML-to-Object mapping
> > - i think it's not a common way, but technically possible.
> > just map the
> > configuration xml to an object and process further.
> > - but... it seems to be more "clean" in design
> >
> > are there other common ways? what is the best practice to load static
> > configuration? and how about loading to a MBean? I wonder the ways can be
> > compared by maintainability, easy of development, easy of learning etc.
> >
> >
> > Regards,
> > mingfai
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
RE: [Configuration/Digester] best practice of loading configuration
Posted by Mingfai Ma <mi...@hongkong.com>.
I'm terribly sorry that this message goes to the list for three times. I
sent it once, and thought it was not delivered, and sent it for the 2nd
times with a slight change in the subject.
sorry for any inconvenience.
regards,
mingfai
> -----Original Message-----
> From: Mingfai Ma [mailto:mingfai@hongkong.com]
> Sent: Wednesday, February 12, 2003 11:14 PM
> To: commons-user@jakarta.apache.org
> Subject: [Configuration/Digester] best practice of loading configuration
>
>
> how do you design your system to load static configuration? there
> are a few
> ways as I know:
>
> 1. Properties.load() or Commons-Configuration
> - the configurations are stored in properties file and is
> loaded to a
> Properties for further processing
> - it's the traditional way
> - the Commons Configuration provides additional benefit as it allow
> repeated value-pair
> (as far as i know, the XML Configuration has
> nothing, so, i don't include
> it)
>
> 2. Digester
> - configurations are stored in xml file, and is processed
> sequentially by
> rules.
> - i used Digestor in one of my project last year. i think
> Digester is
> powerful. but as my configuration was changed a couple of times, it turns
> out I have to maintain the Digester rules which are quite clumsy.
>
> 3. JAXB / XML-to-Object mapping
> - i think it's not a common way, but technically possible.
> just map the
> configuration xml to an object and process further.
> - but... it seems to be more "clean" in design
>
> are there other common ways? what is the best practice to load static
> configuration? and how about loading to a MBean? I wonder the ways can be
> compared by maintainability, easy of development, easy of learning etc.
>
>
> Regards,
> mingfai
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>