commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@t-online.de>
Subject Re: [Configuration] Wish list
Date Thu, 02 Feb 2006 19:04:05 GMT
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


Mime
View raw message