Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: domain of david.vancouvering@gmail.com
 designates 64.233.162.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=LJHTfcT4buO/2+KicMt5+1AKBxH0hlu/Wx5TsX12llIbwr67vYU9T5CDjM+yKa0dbFLPM8K3Eh/vnA877SRoNxMxdYH5U/gyM7yXTa3qjgKnRuBh1QSSnxdba/zZupTcTUpnZDI5aUMuSOAj+Y6FkYBBfym/dXXFn5wYy5dehZk=
Message-ID: <56a83cd00707201034t7b1798fft86d9717201bd832f@mail.gmail.com>
Date: Fri, 20 Jul 2007 10:34:11 -0700
From: "David Van Couvering" <david@vancouvering.com>
Sender: david.vancouvering@gmail.com
To: derby-dev@db.apache.org
Subject: Re: Proposal: default property file
In-Reply-To: <46A0ABFF.9010807@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <20070720091241.tnbbussmysg0kkgo@webmail.ntnu.no>
	 <46A06664.9020707@sun.com> <46A0ABFF.9010807@sun.com>

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 <Vemund.Ostgaard@sun.com> wrote:
> J=F8rgen L=F8land 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 valu=
e
> >>> and default value. This could be helpful information both for
> >>> management/monitoring and perhaps some time for automatically generat=
ed
> >>> 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
>