Re: [Configuration] Wish list

[Borut Bolčina <bo...@najdi.si>]

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

Re: [Configuration] Wish list

[Oliver Heger <ol...@t-online.de>]

Borut Bolčina wrote:

> 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/>
>
Sounds good! I hope I find some time soon to start with the
implementation of the enhanced features for ConfigurationFactory. Then
the XML format will become more specific.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org