commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Verner <br...@rcfile.org>
Subject [configuration] request for comments on refactoring
Date Tue, 18 May 2004 08:25:03 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message