db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering" <da...@vancouvering.com>
Subject Re: Proposal: default property file
Date Fri, 20 Jul 2007 17:34:11 GMT
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.


On 7/20/07, Vemund Ostgaard <Vemund.Ostgaard@sun.com> wrote:
> 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
> 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

View raw message