db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vemund Ostgaard <Vemund.Ostga...@Sun.COM>
Subject Re: Proposal: default property file
Date Fri, 20 Jul 2007 12:35:11 GMT
Jørgen Løland wrote:
> Ole Gunnar Borstad wrote:
>> Siterer Knut Anders Hatlen <Knut.Hatlen@Sun.COM>:
>>> 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 
* 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.


View raw message