Satya Komatineni's Blog

Some code examples demonstrating what I call a Unified Abstract Configuration Pattern

While preparing for an upcoming session at OSCON 2004, I have collected some sample code for dealing with configuration in java applications. The specified URL lists some demonstrative examples of the idea. The examples deal with XML configuration files, Property file configuration files, Reading mandatory keys, Providing default values, Reading objects from configuration files, Configuration as a data source for objects, XML Child attribute equivalence, and Multiple configuration files treated as a single configuration source. See the code examples.

Comments

• Jakarta Commons
  Maybe you would be interested to read this.
  http://jakarta.apache.org/commons/configuration/

  Posted by: abashev on July 14, 2004 at 09:16 AM

• Jakarta Commons
  Thanks for the input. I will certainly take a a look at it as soon as I get a bit of a breather from the OSCON presentation I am preparing for.

  Posted by: satyak on July 14, 2004 at 10:14 AM

• Old School
  I'm now finding this kind of stuff to be "so last year"!

  Of course, I'm not saying I'm above it, because I wrote a library at work 2 years ago that was both similar and more "flexible" (read "complex").

  I've gotten the feeling that having components reaching out into the world to ask for their orders (incl. configuration) will perpetually reveal more problems and complexity.

  Inversion of Control (IoC) is the new wave.

  See:
  Inversion of Control ala. Pico and
  Dependency Injection (another term for IoC) by Martin Fowler

  Posted by: grlea on July 14, 2004 at 10:44 AM

• Some criticisms
  Did you swallow a dictionary??? ;-)

  Seriously though, I did something I considered interesting a while back.

  I found that the Properties class is really easy to work with. And its really easy to load a properties file if you know its name. And its really easy to get the name of your class.

  So I defined one class that loads properties.
  You pass it an object, and it hands you back a properties list from the file which matches that classes name, but with '.properties' as an extension (or whatever you want to use).

  So far nothing special, right?

  Lets look at an example. We have a bunch of say standard emails we want to send out in response to certain events.

  So we've got a properties file like this:
  emailpriority=low
  emailsubject=Hello World
  emailbody=Blah blah blah

  So we can create an OutgoingMail abstract class, and in the constructor of that we load in the properties file, and query and assign the values from the properties file to the instance variables of the abstract class.

  And in this abstract class we can do most of the work of assigning these values into our SMTP message (see JavaMail api for more details, its really easy)

  Now, we subclass the OutgoingMail with different kinds of messages, eg a test message, an emergency message, an we've all been fired, burn down the server room message.... etc.

  And then we.... oh wait, we're done.

  Note that we didn't do any work in the subclasses constructors... they got all their parameters loaded *for free* by the superclass!!! No extra work in the constructor needed.

  --------------------

  But... of course there's always a but.

  What if you start having so many classes that managing hundreds of properties files becomes a logistical nightmare? Well, you don't have to use your own classes name, you can have a 'designated receiver' class which is there simply to hold a bunch of different classes configuration. And so long as there's no property name conflicts, that will work fine.

  What about hierarchical configuration data? This of course puts you back at square one, which is XML. However, you can duplicate some of the hierarchical effect, simply by creating a class hierarchy, though you'd want to be careful that you don't get into a situation where every 'real' class has ten 'fake' classes, just for the sake of configuration.

  ---------------

  Drawbacks:
  The configuration solution that I came up with was really hard to sell to the other developer I was working with at the time. He was very conservative and wanted to go with 'the old way of doing things' - which was to lump all the configuration into one file, and use a name mangling scheme, eg:
  test-emailbody=...
  emerg-emailbody=...
  boss-emailbody=...
  Which required a couple of pages of code per class, rather than my scheme which required a 'fixed cost' of a couple of pages of code, plus a couple of lines of code per property.
  He also had the objection that we couldn't deploy these configuration files in a jar (he didn't understand how to load resources from a jar).... it turned out that the existing applications he'd written deployed their configuration files outside of a jar *anyway*. So that was a non-starter.

  The drawback is that its a bit 'radical' and might be a hard sell to very conservative developers.

  Posted by: rickcarson on July 14, 2004 at 11:15 PM

• Old School
  As you said the work is not ground breaking. But some aspects of it irrespective how old they are are worth stating. I will come to IOC in a minute. But first I want to indicate the importance of "abstraction" (expressed as in implementation independent interface - obvious enough for experienced developers) for configuration. Second point I wanted to make is how the container and contained (components or parts) could use the same abstraction to declare or define their needs. This is where the "unified" came from.

  It is also not uncommon that lot of wise developers ignoring the popular wisdom have developed configuration patterns that are similar in character with varied degrees of need and complexity. For instance Dotnet has half way adated something similar. It is certainly old school. My first implementation of this dates back to 1998 and my first article in 2000 or 2001. Nevertheless I did see container after container released out with out an abstract idea for a configuration and also the api that binds the container to component is in general very poor in services.

  Now to IOC. I did read through IOC. I have read it in particular in the context of factories. Although the container can choose an independent mechanism to fill an object when it is constructed, I felt that the container could benefit from a standardized configuaration to do it from. I also haven't read deep enough to see if IOC can address configuration that is not necessarily tied to objects or in cases where the specification for a configuration need is more round about than actually asking for it.

  Thanks for the input though, and also the references to the IOC articles
  Satya

  Posted by: satyak on July 15, 2004 at 03:44 AM

This work is licensed under a Creative Commons License.