I like these sanity checks Vemund. Then of course, there is nirvana: getting rid of using system properties for configuring Derby. That is *so* nineties :) And of course it makes it very hard to have two different Derby systems running in the same VM, even though they're in different classloaders. But I digress.
David On 7/20/07, Vemund Ostgaard <[EMAIL PROTECTED]> wrote:
Jørgen Løland wrote: > Ole Gunnar Borstad wrote: >> Siterer Knut Anders Hatlen <[EMAIL PROTECTED]>: >>> >>> We could also take the idea one step further and create a file with >>> meta-data about the properties, for instance a description, whether >>> it's >>> a database property or a system property, minimum value, maximum value >>> and default value. This could be helpful information both for >>> management/monitoring and perhaps some time for automatically generated >>> documentation. >> >> I like this idea, it's pretty much what Derby is lacking wrt. >> properties; A clean and comprehensible interface. I don't know if this >> has to be done the hardcore way with XML or something, or if we could >> just do it with commenting. I think derby.properties uses # for >> comments. Keeping it simple is a must I guess? >> > > Storing default property values in a default.properties file sounds > like a very good idea. Personally, I think the way properties are > handled in the Derby code is developer-unfriendly with the mixture of > hardcoded variables and Property objects. Every now and then, I have > to text-search for a property name and see what the value of the > alternative is. A properties file in derby.jar would make this much > easier. > > If possible, I think it would be good to use the same format for this > file and derby.properties. Since the format of derby.properties has > already been defined, I think it would be better to go with that than > with xml. Just my $0.02. > I have been involved in a similar refactoring for a java based test harness. We had found that properties often where the source of errors both in code and in the use of the system, because of typos and the difficulty of maintaining it over time (removing properties no longer in use, old property files used on a new version of the product, etc.). After having created a separate property file for defaults, much as you have suggested here, we also added several checks to the system: * The contents of the property file supplied by a user was checked for typos and version compatibility by requiring all properties in it to also be present in the default file. This can be a bit strict I guess, but it should at least give a warning I think if you supply a property the system doesn't know about. For us it caught and helped diagnose many problems. * When code tried to get the value of a property that wasn't in the default file, this caused an Exception. This helped avoid developers forgetting to update the default file, and caught typos in property names in the code. * A test can also verify that all properties in the default property file are actually used somewhere in the code. Vemund
