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: >> >><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: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > -- > bLOG <http://www.delo.si/blog/borutb/> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
