commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthijs Wensveen <>
Subject New commons subproject vs. Configuration project
Date Tue, 15 Jul 2003 10:16:05 GMT
I am a certiefied Java programmer and work for a small Web development / 
Internet application company in the Netherlands. We have recently 
developed a system to configure web applications and standalone 
applications in a standard way.
In some ways it looks like the Configuration subproject, but in other 
ways it is different.
Our idea was to keep configuration information as centralized as 
possible. While it is possible to use multiple configuration files, 
users are encouraged to use only one configuration file.
Another difference is that our configurator was meant to look a bit like 
a JNDI, no matter if there is a real JNDI on the background or just an 
XML file containing data.
This also means it is possible to 'lookup' entire objects from the 
configurator. An obvious example would be a Properties object, but there 
is no real limit. You can write your own plugin to parse a piece of the 
configuration and supply you own objects if you want. Or just use the 
configuration data to configure a Logger, for example. I think this is 
its greatest strength.
The XML you use is undefined, because different plugins can parse 
different pieces of XML.

I think that our configuration system is very useful for the open source 
community, but I don't know if  there is place for two different 
configuration systems in the Jakarta Commons project.
Maybe it's possible to use each others ideas.
If anyone is interested, I can provide full source, examples, 
documentation and javadocs, or just some extra info.

Matthijs Wensveen.

PS. It is possible to use the org.apache.commons.configuration classes 
*in* 'our' configuration system. And it's probably also possible to 
write a commons configuration class that uses 'our' configurator.
PPS. Currently we have both SAX and DOM implementations, but if a JDOM 
implementation is preferred it should be easy to write.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message