Alternatives to property files

[Kenneth P. Turvey]

I'm writing some code that requires a configuration file to be edited by
the end user. The end user may also provide classes for describing
problems to be solved by the software. There are a number of such classes
describing problems and algorithms already provided. I would like the end
users to be able to use custom configuration options in the same file that
the system configuration options are provided.

This works fine with properties files, but then I have to have generic
methods to get the properties back, things like getConfigurationInt().
This is a bit annoying and looks bad in the code. One would prefer that
the user be able to register their own properties to be retrieved and the
defaults for these properties, and even possibly the method names to get
and set them. One would also wish to be able to print out a file that
includes all the properties that are in use by the program including those
that are not set, but defaulted. The idea being that one would be able to
duplicate the run at some future date by using the resulting configuration
file, or understand exactly what options the user had when using the
program.

There are other problems too. Ideally this would all be easy to use in
testing. Right now I have a singleton class that wraps around the
properties and provides getters and setters for some of them. It just
doesn't work well for testing.

So some framework that would ease testing would be preferred.

Is there something out there that I might want to try?

Any ideas?

Thanks.

 

[Daniel Pitts]

I'm writing some code that requires a configuration file to be edited by
the end user. The end user may also provide classes for describing
problems to be solved by the software. There are a number of such classes
describing problems and algorithms already provided. I would like the end
users to be able to use custom configuration options in the same file that
the system configuration options are provided.

This works fine with properties files, but then I have to have generic
methods to get the properties back, things like getConfigurationInt().
This is a bit annoying and looks bad in the code. One would prefer that
the user be able to register their own properties to be retrieved and the
defaults for these properties, and even possibly the method names to get
and set them. One would also wish to be able to print out a file that
includes all the properties that are in use by the program including those
that are not set, but defaulted. The idea being that one would be able to
duplicate the run at some future date by using the resulting configuration
file, or understand exactly what options the user had when using the
program.

There are other problems too. Ideally this would all be easy to use in
testing. Right now I have a singleton class that wraps around the
properties and provides getters and setters for some of them. It just
doesn't work well for testing.

So some framework that would ease testing would be preferred.

Is there something out there that I might want to try?

Any ideas?

Thanks.

You might look into the Spring Framework. Its a little heavyweight, but
IMO worth it. Basically, you're code doesn't instantiate any of its
"configurable" objects itself, this is done by the framework, and those
instances are passed into your objects where they belong. You
"configure" it by specifying an Application Context file, and this file
is in XML format.

This works well with JUnit, because you can specify a "testing" context,
and then override specific parts in your test code with mock objects.

HTH,
Daniel.

 

[Stefan Ram]

So some framework that would ease testing would be preferred.

Unotal is a language like S-expressions with attributes
or XML without end tags and with structured attributes.

Junotal is a Java implementation that allows to read
and write Unotal. Unotal expressions are mapped to
Java maps and lists and therefore can be used easily.

While this is an alternative to Java SE property files indeed,
I am afraid that it does not fulfil your other requirements.

http://www.purl.org/stefan_ram/pub/junotal_tutorial

 

[Ed Kirwan]

I'm writing some code that requires a configuration file to be edited by
the end user.

snip

One would prefer that
the user be able to register their own properties to be retrieved and the
defaults for these properties, and even possibly the method names to get
and set them.

I don't understand this.

Is the user here a user of your finished product? Why would such a user want
to know about method names?

I'm sure I've misunderstood: properties that a software user alters are only
relevant in that these properties alter the behaviour of the software. So
how could a user register properties ad-hoc that could then alter the
behaviour of the software written before the user thought of the
behaviour-altering properties.

I suppose what I'm asking for here is an example of one of these properties
that the user could register.

 

[EricF]

You might look into the Spring Framework. Its a little heavyweight, but
IMO worth it. Basically, you're code doesn't instantiate any of its
"configurable" objects itself, this is done by the framework, and those
instances are passed into your objects where they belong. You
"configure" it by specifying an Application Context file, and this file
is in XML format.

This works well with JUnit, because you can specify a "testing" context,
and then override specific parts in your test code with mock objects.

HTH,
Daniel.

Agreed. I was going to suggest Spring Beans but Daniel beat me to it.

Eric

 

[Kenneth P. Turvey]

I don't understand this.

Is the user here a user of your finished product? Why would such a user want
to know about method names?

I'm sure I've misunderstood: properties that a software user alters are only
relevant in that these properties alter the behaviour of the software. So
how could a user register properties ad-hoc that could then alter the
behaviour of the software written before the user thought of the
behaviour-altering properties.

I suppose what I'm asking for here is an example of one of these properties
that the user could register.

The end user will be writing classes that implement their particular
problem or provide customization that they need, so they will be
interested in properties that didn't exist until they thought of them.

The user may be more sophisticated than most.