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
