Return-Path: 
 <commons-user-return-15024-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 73630 invoked from network); 28 Jan 2006 10:46:15 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 28 Jan 2006 10:46:15 -0000
Received: (qmail 89555 invoked by uid 500); 28 Jan 2006 10:46:10 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 89540 invoked by uid 500); 28 Jan 2006 10:46:10 -0000
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-user-help@jakarta.apache.org>
List-Post: <mailto:commons-user@jakarta.apache.org>
List-Id: "Jakarta Commons Users List" <commons-user.jakarta.apache.org>
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 89528 invoked by uid 99); 28 Jan 2006 10:46:10 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jan 2006 02:46:10 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=UNPARSEABLE_RELAY
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [194.25.134.17] (HELO mailout02.sul.t-online.com)
 (194.25.134.17)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jan 2006 02:46:09 -0800
Received: from fwd35.aul.t-online.de
	by mailout02.sul.t-online.com with smtp
	id 1F2naW-0002HM-00; Sat, 28 Jan 2006 11:45:48 +0100
Received: from [192.168.0.1]
 (rAVGHZZ1gedtLbo8MbzeqUzTHtSCEB5tntRfisC-lM9mlp5NyZVnQw@[84.174.126.5]) by
 fwd35.sul.t-online.de
	with esmtp id 1F2naL-0veUkK0; Sat, 28 Jan 2006 11:45:37 +0100
Message-ID: <43DB4B54.7030209@t-online.de>
Date: Sat, 28 Jan 2006 11:45:40 +0100
From: Oliver Heger <oliver.heger@t-online.de>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [Configuration] Wish list
References: <43D88684.9060008@najdi.si> <43D8ADCF.2060608@med.uni-marburg.de>
 <43D8BB69.9060709@najdi.si> <43D928AE.7000104@t-online.de>
 <43DA2FEB.8050004@najdi.si> <43DA3AD6.5060702@t-online.de>
 <43DA58FE.7040709@najdi.si>
In-Reply-To: <43DA58FE.7040709@najdi.si>
X-Enigmail-Version: 0.92.0.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ID: rAVGHZZ1gedtLbo8MbzeqUzTHtSCEB5tntRfisC-lM9mlp5NyZVnQw
X-TOI-MSGID: d025673e-6d74-463e-9f55-a7de74273638
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org