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 Sat, 28 Jan 2006 10:45:40 GMT
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.

> 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

    <!-- Definition of configuration sources that override properties -->
    <!-- Definition of configuration sources that are combined -->

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

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.

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

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.

What do you think? Is this all information you need for a schema?


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

View raw message