XML ain't a programming language

I happen to consider Spring a pretty nifty framework. Actually, many of the developers I know consider it nifty and I don't have any reasons to object. It is well-documented and rich in functionality.

After spending a day reading the documentation, I came to the conclusion that I had not understood it well enough and resolved to reread it at a later time.

The ability to configure a large application at deployment time through configuration files is hardly a new concept. Every Servlet container does it. Log4j does it. Logback does it, as well as any serious framework with an emphasis on flexibility and extensibility. Logback uses Joran package for its configuration parsing. Joran is derived from Jakarta Digester. Although amazingly powerful in certain aspects, as Jakarta Digester, it is not a general bean definition package.

IOC frameworks offer functionality beyond Digester derived configurators, in particular the ability resolve circular bean dependencies. You can configure many if not hundreds of beans using Spring. Unfortunately, this will cause your beans.xml to balloon to gargantuan proportions.

It seems that Spring allows a beans.xml file to be broken to smaller chunks by importing bean definitions from another file. I find it far more difficult to read bean definition files in XML than Java code. The difficulty increases exponentially with the size of the bean definition file. However, according to the documentation, the list of imported files must precede beans definitions in the importing file – a rather severe and unexpected restriction to say the least.

My impression is that IOC frameworks such as Spring need to offer support for a very large set of tools to be useful. Sucking in ever larger parts of the Java universe, it reinvents the Java language in XML. However, XML does not make a fun programming language.

I wonder if it is possible to deliver the promise of IOC non-intrusively and without resorting to large XML files.

Interestingly enough, unit testing presents a similar set of problems. However, as larger and larger portion of the Java universe gets mocked, we get farther and farhter away from the sprit of unit testing. Altough configuring unit tests is sometimes a non-trivial task, as far as I can tell, unit testing does not seem plagued by large config files in XML.