commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Borut Bolčina <...@najdi.si>
Subject Re: [Configuration] Wish list
Date Thu, 02 Feb 2006 07:00:15 GMT
Hi, sorry for late response, quite busy days...

On 28.1.2006 11:45, Oliver Heger wrote:
> Borut Bolčina wrote:
>
>   
>> Hello Oliver,
>> I understand now. I suppose each configuration class can have a well
>> defined set of accessor methods (settings) that can be included in
>> configuration.xml. If so, then making a schema is a no-brainer.
>>     
>
> That's correct, but we need to keep in mind that new accessor methods
> may be added in a new release. Then the schema has to be updated.
>   
Yes. There should be versioned shemas on some public server. I guess API 
should not change several times a year.
>   
>> When agreed upon, you can send me sample example files and I will make
>> an XML Schema (xsd).
>>
>> bye,
>> Borut
>>     
>
> Okay, the skeleton of a configuration definition file looks like the
> following:
>
> <configuration>
>   <override>
>     <!-- Definition of configuration sources that override properties -->
>   </override>
>   <additional>
>     <!-- Definition of configuration sources that are combined -->
>   </additional>
> </configuration>
>
> Both the <override> and <additional> elements are optional. It is
> possible that configuration sources are defined outside these elements
> (i.e. as direct children of the root node), then they are treated as if
> they were placed inside an <override> section. (This is perhaps a bit
> ugly, but I fear we will have to keep this because of backwards
> compatibility.)
>   
I think it can be done, but yes, it is ugly.
> A definition of a configuration source at the moment simply consists of
> one of the tags mentioned in the howto about ConfigurationFactory
> (http://jakarta.apache.org/commons/configuration/howto_configurationfactory.html).
> It can have attributes that correspond to the setter methods defined in
> the configuration class represented by this tag (the information, which
> class is used by which tag can also be found in the howto document,
> section "The configuration definition file"). I think it will be
> necessary to look up the JavaDocs for these classes to find out the set
> of attributes needed by a tag.
>   
I'll look it up.
> Currently only primitive values can be set this way. I would like to
> enhance this to also support arbitrary objects. This will be required
> for things like reloading strategies or expression engines. My idea
> about how such a complex declaration could look like is to define these
> object settings as sub elements of the tag for the configuration source,
> e.g.:
>
> <properties fileName="my.properties">
>   <reloadingStrategy
> class="o.a.c.configuration.reloading.FileChangedReloadingStrategy"
>       refreshDelay="10000"/>
> </properties>
>
> The sub elements' names would correspond to the names of the setter
> methods in the configuration class. In theory this game could be
> continued if the object defined in the sub element has itself complex
> settings, which in turn could be defined in sub (sub) elements. I guess,
> here it becomes complex, but such a format would really be convenient to
> setup your configurations.
>   
Those objects can be accounted for by *any* element in schema language, 
but this means some sections of the configuration file will not be 
validated. Since the majority of them will be simple, a shema will cover 
most user needs. In case some complex objects initialization will become 
more common, their validation can be added into the schema later.
> What do you think? Is this all information you need for a schema?
>   
For starters yes.
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>   
-- 
bLOG <http://www.delo.si/blog/borutb/>


Mime
View raw message