Hi all.
I've been itching to use commons-configuration as the backend
for my own config system, but I've found myself refactoring the heck
out of commons-configuration along the way :-)
So here goes what I'd think like to see commons-configuration look
like at the end of it all. I'd appreciate any comments and/or
suggestions on the idea of refactoring commons-configuration and
on the specific ideas sketched below.
As you'll see further down, my vision of using commons-configuration
would become as simple as:
#
# begin contents of "/path/to/a/file.properties"
#
include.some.file: file:relativeFile.properties
include.some.jdbc: jdbc:...
include.some.jndi: jndi:...
include.another.file: file:/absolute/path/to/file.xml
#
# end example properties file
#
CURL curl = new CURL("file:/path/to/a/file.properties");
//
// no includes handled... configuration will have only
// the four keys above.
//
Configuration singleSourceConfiguration = curl.load();
//
// or to load configurations with "include"d files.
//
CompositeConfiguration multipleSourceConfiguration = new CompositeConfiguration();
curl.load(multipleSourceConfiguration);
[p.s., I'm aware CURL is probably a bad name to use, but that's
what it ended up being, and its way too late for me to be
re-editing this mail ;-) Maybe ConfigurationURL,
ConfigurationSource or ConfigurationLoader might work.]
org.apache.commons.configuration
Configuration
CompositeConfiguration
ConfigurationComparator
ConfigurationUtils
StrictConfigurationComparator
CURL - entry point for loading configurations. basically,
a CURL is a primitive URL-like object takes a
Configuration URL, i.e.,
file:/path/to/file.${EXTENSION}
res:/path/to/file.${EXTENSION}
jdbc:${JDBC_URL} [1]
jndi:${JNDI_URL} [1]
and instantiates w "handler" to actually manage the
requested configuration. I _think_ I'd like for
UndefinedHandlerException - thrown when CURL handler is not found
??? [other bits from commons-configuration that should be here]
[1] I've not looked far enough into jdbc and jndi configuration
providers to know what the CURL would need to contain...
org.apache.commons.configuration.event
ConfigurationChangedListener - receives notification when a
Configuration has changed
ConfigurationChangedEvent - sent by a ConfigurationProvider
when its Configuration (or storage) has been modified.
In my config system, I have a FileModificationMonitor
subsystem (probaby to be renamed to ResourceModificationMonitor
and contributed to a suitable jakarta project) that checks
files for modification and sends a FileModifiedEvent to
a listener.
org.apache.commons.configuration.provider
ConfigurationProvider - interface used by Handler to manage
underlying Configuration, delegated
to by Handlers. defined load(..),
store(...) and other relevant
methods.
... [current Configuration providers, updated to adhere to
new ConfigurationProvider]
org.apache.commons.configuration.handler
Handler - interface for CURL "protocol" handlers, basically
defining load(...) and store(...) methods which
would delegate to an appropriate ConfigurationProvider
org.apache.commons.configuration.handler.jndi
Handler - handler for "jndi:" CURL - jndi-backed configuration
org.apache.commons.configuration.handler.jdbc
Handler - handler for "jdbc:" CURL - database-backed configuration
org.apache.commons.configuration.handler.res
Handler - handler for "res:" CURL - Classloader.getResourceAsStream()
org.apache.commons.configuration.handler.file
Handler - handler for "file:" CURL - any local file-based
configuration. Would have logic to select a
ConfigurationProvider implementation based on CURL
attribute such as file extension.
org.apache.commons.configuration.handler.http
Handler - handler for "http:" CURL - an http:// hosted configuration
similar logic to choose ConfigurationProvider based
on CURL attributes.
The reason I think Handlers and ConfigurationProviders should
be separate is to allow the Handler to choose the ConfigurationProvider
based on CURL attributes (most notably file extension...)
I've made an initial pass at implementing most of such a system
from the existing commons-configuration bits, and would be most
happy to put the stuff into CVS (somewhere?) if anyone is interested
in helping out.
I'm still a bit blurry on how best to handle the "include"
feature, but ISTM it might be best to handle the inclusion
of additional configurations in the CompositeConfiguration
class, and get rid of the BasePath[Loader|Configuration]
bits altogether. Comments/Suggestions especially appreciated
here :-)
There are a ton of other (important, even) details that I've
probably glossed over, but I hope the above paints a sane
enough picture to spark discussion.
BTW, is there any reason that PropertiesConfiguration should
not be made to be compliant with java.util.Properties files?
I'm aware of the current duplicate-keys-create-lists behaviour,
but IMO, it would be best to have the _same_ semantics as the
java.util.Properties files. There is no reason we couldn't have
the current custom-parsed properties file provider along
side a standard Properties file provider.
<wipes brow> phew...
thanks.
brent
--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
