Wednesday, July 06, 2005

Compilable Configuration

Just assembling thoughts on ways to build a system for configuring applications using code instead of text files (ini, xml, properties, etc.)

The simplest immaginable would be to specify the class name in a property set at startup.
java -Dconfig.class=com.willcode4beer.conf.MyConfig ....
This is quick and simple but, it could get complicated when multiple configurations need to be used. It does make it easy to swap test and real configurations.
Some of these could be resolved by writing a startup wrapper class that tells the application where to find its configuration classes.

Another would be to define an interface for the configuration and at startup use a custom class loader to scan all entries on the classpath looking for classes that implement the interface and calling their initialization method. This would result in a longer startup time but would be easy to use in closed applications designed to be pluggable. There is also the problem of swapping test configurations for real ones.

Why am I doing this?
  • I am a strong believer in strong typing (and strongly typed languages). This removes all doubt that a configuration (or code) is correct.
  • I believe it is a GOOD idea to use the (well tested and proven) tools at hand. Strongly typed code means the compiler can be used to help PREVENT bugs.
  • The compiler will let you know about typos.
  • This will point out problems earlier (compile time vs. run time).
  • The idea of non-developers reconfiguring a complex application is a myth, lets just let it go.
  • A muti-thousand line xml configuration file is hell to work with.
Thoughts on implementations:
Define configuration interfaces. These should define what the configuration provides. If there are optional things, they should be documented. Abstract classes could be built for configurations that have optional methods to make peoples lives easier.
Develop to interfaces - Configuration interfaces should define methods that return interfaces instead of classes. This gets rid of weird hierarchys, and provides lots of flexibility.
Put all of the configuration classes in one package. This makes it easier to find them all.
Put all of the configuration interfaces in one package. This makes them easier to find and the javadocs will be together.
Write detailed javadocs in the interfaces. Let these be the only "real" documentation for the configuration. Its easier to do because its close to the code and it'll be the first place a developer will look. This beats the hell out of digging for documentation in random forums.

Just my thoughts. I'll put on some polish while working on some other applications.

Links to this post