8 October 2006 - 16:31Spring config as code

I was reading (belatedly) Crazy Bob’s rant about Spring. It is an interesting point, the fact that your configuration settings become code because they do what code is meant to do, that is, they implement a desired behavior. Yes, the lines between configuration and code blur, just look at the number and size of various XML descriptors which are popping up everywhere. So, I would say the Bob was right about the fact that your Spring XML descriptor is code.
However, he was definitively wrong about Spring configuration file being intrusive. Yes, you need such a file for your application to be bootstrapped correctly, but you do not need to abide by Spring’s XML descriptor. The Spring XML descriptor is a window onto a particular binding mechanism, there is nothing that requires you to use this particular file. You can set-up your configuration syntax, write a parser around it, plug this parser into the IoC for application bootstrap and have Spring use your own bootstrapper with your own semantics. It is not going to happen over-night, you will probably need an in-depth knowledge of Spring, but if you are concerned about developing in an intrusive environment you may want to look at it. (One danger of going this route is that your syntax will diverge from Spring’s syntax and new additions to the framework’s syntax (such as AOP) will have to be re-developed according to your environment. In the case of an IoC container using a different syntax is very similar to forking a project and has pretty much the same synchronisation problems.)
Another option would be to create your syntax, have a translator which converts your XML descriptor into an Spring XML descriptor and have your application run on the Spring descriptor your translator would produce. You are running the same dangers as before since you are basically forking a language.
Or you could take a look at the XML namespaces that have been added to Spring 2.0 which include extended XML authoring and have all your problems resolved (you can find a small tutorial here). I really like the fact that the Spring community decided to do away with the only thing in the framework which cold have been regarded as intrusive and to do it in style ;-). Again, the Spring XML descriptor was just a window onto a binding mechanism which could have been replaced/enhanced with another window at various costs. It was not intrusive, it just carried a lot of weight. Well, this weight disappeared. Nice move.

2 Comments | Tags: Development

Comments:

  1. You’re right on the money about the fact that Spring is decoupled from XML. In fact for quite a long time, Spring has actually supported using property files for configuration. I think however, that it is very telling that no one uses it. Given the choice, users have overwhelmingly chosen XML. That being said that we definitely heard the complaints about our XML configuration. And thanks to the fact that we’re decoupled from XML, plugging in the XSD support and namespaces was trivial. Not only is it easy to plug in other flavors of XML, but there a plans to allow configuration based on Java classes, Groovy files, etc. and they’ll all go in with the same ease (knock on wood).

  2. When you are using code (Groovy files) for configuring your application it is a safe bet that configuration is becoming very complex to the point where it cannot be expressed only in “traditional” ways (XML files, property files, etc…). The difference between code and configuration is becoming blurred indeed…

Add a Comment