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
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.)
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.
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.
What do you think? Is this all information you need for a schema?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
