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