commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <heg...@med.uni-marburg.de>
Subject Re: [configuration] Roadmap
Date Fri, 05 Mar 2004 07:31:32 GMT
Just a view remarks about refactoring ConfigurationFactory:

One could argue that ConfigurationFactory already provides a means to 
plug in implementations for other configuration sources. The class uses 
[digester] to process the configuration definition file, and it is 
possible to define a custom set of digester rules. This allows for 
processing completely different tags.

Well, this is surely not the best solution (and it requires certainly 
some knowledge about internal processing logic), but I am a bit curious 
what you are going to refactor. One thing to keep in mind is that the 
sub tags that load configuration sources can appear in an <overload> and 
an <additional> section with different behavior.

I was thinking of re-implementing the union configuration mechanism in 
ConfigurationFactory. My idea is to provide a UnionConfiguration that is 
initialised with a CompositeConfiguration and provides a readonly union 
view on the properties defined there. Here such concepts like readonly 
configurations and observable configurations (for keeping the view up to 
date), which were also mentioned on this thread, come into play. This 
would simplify the loading of a ConfigurationFactory and probably also 
implementation of the later planed reloadable configurations. But I 
think this issue won't be addressed before the 1.0 release.

Oliver

Jörg Schaible schrieb:
> Emmanuel Bourg wrote on Thursday, March 04, 2004 2:48 PM:
> 
> 
>>There has been some good ideas coming around [configuration] lately,
>>I'd like to suggest a roadmap to sort what needs to be done
>>before the 1.0
>>release and what could be added later:
>>
>>configuration 1.0
>>
>>- make PropertiesConfiguration a full replacement for
>>ExtendedProperties: add headers to .properties files (Bug 26092) and
>>make Configuration extend Map.
> 
> 
> remove here also the dependency to StringUtils (just used to handle an empty String).
Basic idea - if I just use properties and DOM, I would like to have the least number of dependencies
as possible. If other lang functionality would have been used here, no problem - but *not*
for an empty String test ...
> 
> 
>>- comma separated values revamp
>>- DOM4J dependency removal
> 
> 
> Working on this. I understand correctly, that this just means support of DOM, but no
deprecation of JDOM ?
> 
> 
>>- add DatabaseConfiguration support to the ConfigurationFactory
> 
> 
> Working also on a "pluggable" ConfigurationFactory. What is the intension for the functionality
of the current ConfigurationFactory ? Support any Configuration type (= backward compatibility)
? I would introduce an AbtractConfigurationFactory refactoring the common parts. Name of the
PluggableConfigurationFactory (ConfigurableConfigurationFactory <g>) ? Introduce a Jdk14ConfigurationFactory
(with least number of dependencies) ?
> 
> 
>>- remaining bugs (26944, 26534, 27427)
>>- more documentation, examples and tutorials
> 
> 
> Will provide unit tests and docs for my new classes.
> 
> 
>>configuration 1.1
>>
>>- reloadable configurations
>>- web configurations
>>- additionnal types (URL, Locale, Date, Calendar, Color)
>>- list getters for all types
>>- setters for all types
>>- INI file support
>>- system properties interpolation (Bug 26066)
> 
> 
> Can we introcuce a basic support for 1.0 (I will need this anyway)? I am thinking of
a SystemPropertyConfiguration as singleton. Does that make sense? You could use it in a composition.
Or do you think of an implicit support in interpolateHelper ?
> 
> 
>>- ConfigurationFactory refactoring for pluggable extensions
> 
> 
> See above - already on the way.
> 
> 
>>configuration 1.2
>>
>>- comments & layout preservation in .properties files
>>- JMX integration ?
>>- Preference API integration ?
>>- observable configurations ?
> 
> 
> Regards,
> Jörg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
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