Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 62224 invoked from network); 2 Feb 2006 19:42:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Feb 2006 19:42:30 -0000 Received: (qmail 65143 invoked by uid 500); 2 Feb 2006 19:42:14 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 64992 invoked by uid 500); 2 Feb 2006 19:42:13 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 64935 invoked by uid 99); 2 Feb 2006 19:42:13 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2006 11:42:13 -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; Thu, 02 Feb 2006 11:42:10 -0800 Received: from fwd31.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1F4joN-0001aA-00; Thu, 02 Feb 2006 20:08:07 +0100 Received: from [192.168.0.1] (S9xxWcZbYeB53CjvMFzTQbQnMVbbZaPrsOzB4BtlJxdVyz7iBYCwgn@[84.174.82.193]) by fwd31.sul.t-online.de with esmtp id 1F4jkT-1FQMm80; Thu, 2 Feb 2006 20:04:05 +0100 Message-ID: <43E257A5.6040008@t-online.de> Date: Thu, 02 Feb 2006 20:04:05 +0100 From: Oliver Heger User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Users List 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> <43DB4B54.7030209@t-online.de> <43E1ADFF.10804@najdi.si> In-Reply-To: <43E1ADFF.10804@najdi.si> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ID: S9xxWcZbYeB53CjvMFzTQbQnMVbbZaPrsOzB4BtlJxdVyz7iBYCwgn X-TOI-MSGID: c9e4942a-b36b-4479-91f9-0129ce56a031 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: > 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: >> >> >> >> >> >> >> >> >> >> >>Both the and 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 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.: >> >> >> >class="o.a.c.configuration.reloading.FileChangedReloadingStrategy" >> 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. > >>Oliver >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >>For additional commands, e-mail: commons-user-help@jakarta.apache.org >> >> >> > -- > 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. Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org