commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
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).
>>Okay, the skeleton of a configuration definition file looks like the
>>  <override>
>>    <!-- Definition of configuration sources that override properties -->
>>  </override>
>>  <additional>
>>    <!-- Definition of configuration sources that are combined -->
>>  </additional>
>>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
> 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
>>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,
>><properties fileName="">
>>  <reloadingStrategy
>>      refreshDelay="10000"/>
>>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.
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> -- 
> bLOG <>
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message