Update (5/25/2004): I'm learning more about Groovy and Groovy Markup check out this posting Groovy Markup BeanBuilder for the basis for an alternative strategy which I'm working on.

The proliferation of XML files for configuration bugs me. All of the XML configuration mechanisms I have looked at are used to create and wire application objects together at launch time. I'm the lucky one who gets to write and maintain these files. Framework developers have to write and maintain thousands of lines of code for processing XML files, and creating objects based upon them. There must be a way to achieve the same end which lets me forget about XML and absolves the framework developer of the need to maintain so much XML parsing code.

I started looking at Groovy a few weeks ago and liked what I saw. I worked with Objective-C before I picked up Java so it's nice to see some of the more dynamic features I was used to creeping into a JVM compatible language, even if it is a scripting language.

So, I thought, can I use Groovy scripts instead of XML configuration files to wire my application objects together? As a proof of concept I opted for scripting a Spring configuration. Spring is a (buzzword)"lightweight container" where JavaBeans are declared as named items in an XML configuration file and can be wired together to construct application services.

I delved into the XML parsing code to find the objects created by the processing of the Spring configuration files. All the processing involves creating a bean definition object, with optional constructor arguments and bean property values. Once the bean definition is created it is then registered with the ApplicationContext.

I used the WebApplicationContextTestSuite class in the Spring unit test suite as the basis for my experiment. This is a test of the XmlWebApplicationContext class with 40 unit tests based upon 2 XML configuration files. The fragment below is the first bean declaration from the applicationContext.xml file used in the test:

I implemented my own GroovyWebApplicationContext class to accept .groovy files instead of XML files, This was an easy task once I figured out how the whole ApplicationContext class hierarchy was structured, The main code for processing the groovy scripts looks like this:

Each script has access to an appContext variable which is a reference to the application context. I added a couple of convenience methods to the context to make creating the bean definitions more script friendly and the XML bean configuration shown above came out in Groovy as:

This seems at least as clear as the XML configuration files and a little more terse.

I replicated both of the test-suites' XML files as Groovy scripts and ran the test suite. 2 of the bean definitions declare beans as instances of inner classes and I could not get the Groovy parser to recognize the inner class declarations so I commented them out. Out of 40 tests 37 passed, 2 had errors (due to the commented references to inner classes) and 1 failed.

You can download the source code for this example: groovy-spring.tgz, I tested with Spring version 1.01 and added Groovy 1.0, beta 4 to the project dependencies.

There must be hundreds of thousands of lines of custom XML-parsing, class-loading, object-instantiating, bean-wiring code sitting inside hundreds of open and closed source projects. Most of the XML files parsed by this code will be written by Java developers. Why not instead implement configuration with clean JavaBean interfaces and let a scripting language do the job? No need to write, debug, test any XML parsing code, no need to update DTD files and parsing code as the configuration parameters evolve, just add more JavaBeans, properties and or methods.