Configuration Notations

I've been using XML as a configuration notation since I've started doing web development. It's a basic building block when it comes to Java EE. Unfortunately I think it's also one of the most common source of errors, especially because there's no compiler which tells you what's wrong. How many times have you deployed your web app in a Java EE container, only to find out, that you have a typo in your web.xml. One advantage of XML, in my opinion, is readability. If you have a configuration file, XML does a decent job in suggesting what you are actually trying to configure and how it relates to your code. I do admit that it can become very verbose very quickly, but using XML namespaces, like the Springframework, you can keep it under control - at least to a certain extend.

I'm currently working on a project which leverages the Springframework. We are using the container to manage dependencies, Dynamic Modules to leverage OSGi and a lot of other stuff which sometimes makes life easier. Spring's default configuration option is XML. So if you want the Spring container to know about your class you'd write something like the following:

<bean id="person" class="de.linsin.sample.spring.contracts.PersonImpl"/>

Of course that's not the whole story, there's lot's of namespace configuration and all the other XML stuff in your configuration file. Basically every class you want Spring to know about, needs a complement in your configuration. It quickly gets more and more, e.g. if you add transaction management or logging. In short: your XML configuration virtually outgrows!

I said this before, but here it is again: I like Spring's XML configuration and I believe it's all a question of proper tooling. If you have a tool like IntelliJ IDEA, it's a lot easier to handle your Spring configuration.

There's another configuration notation, which has been around for a while: properties files. They contain simple key value pairs:

authentication.factory=de.linsin.sample.factory.LDAPAuthFactory
admin.email=dlinsin@gmail.com

In my last project, we used properties files excessively to configure global variables, which are set at startup of the Java EE container for the lifetime of the JVM. Properties files are also the standard way of internationalizing your application. For each language you can provide a file which contains keys that are used throughout your application and values, containing the translated messages. The keys are being substituted at runtime with the appropriate values, depending on the currently chosen language. As with XML, there is no compiler warning or static check, which could tell you that you haven't configured your properties file correctly. It's generally a good idea to add a null check before accessing a property, since it can lead to nasty NPEs if it's undefined. In my opinion readability of properties files can't keep up with XML. Usually your files are sprinkled with comments, which indicate where and how the properties are used. That doesn't really scale and comments are not always the best way of enforcing a contract.

Another problem with properties files is encoding. As soon as they contain none Latin-1 characters, you need to do extra work more work to avoid problems. Usually you shouldn't have those encoding problems with XML. Proper tooling is a real problem when it comes to management of properties files. I haven't found a really good tool, which conducts some kind of check if my code and properties files are in-sync. I have to plug IntelliJ again here. They are doing a somewhat reasonable job of managing your properties.

One of the most exotic configuration notation, at least in my opinion, is JSON. Yes, I know! You are probably raising your eyebrows right now, like I did the first time I read about it. JSON is used as the configuration notation of SpringSource's Application Platform - S2AP. You can among other stuff configure logging using JSON:

"trace": {
"directory": "serviceability/trace",
"defaultLevel": "info",
"specificLevels": {
"com.foo.*" : "verbose",
"com.foo.UnimportantClass" : "info",
"com.bar.ImportantClass" : "verbose"
}
}

As probably most of you, I've used JSON only for web development. I think its most common application is calling server-side code from JavaScript. Using it for configuration is an interesting idea, though. When looking at the example above, I think the readability is quite reasonable. The hierarchical structure, similar to XML, makes it easy to figure out what you are trying to configure. There are frameworks out there, which are converting JSON to Java and vice versa, so there's no need to write a parser yourself. Like with the perviously mentioned notations, catching mistakes before deployment is rather limited, since there is no compilation step involved. As for tooling, every decent IDE supports JavaScript nowadays and most of the time that includes JSON. It shouldn't be a problem, getting some tool support when editing JSON snippets.

Comparing these different configuration notations rather subjectively, there is no clear winner for me. The only real difference is proliferation. Despite its somewhat bad reputation, XML is clearly the most widely used configuration notation, directly followed by properties files. JSON is kind of the "new kid on the block", because I've never seen it being used for configuration, before S2AP.

Besides its wide usage and ubiquity, XML has DTD and namespaces, which I believe can eliminate the two major downsides: verboseness and misconfiguration. The strong tool support, which came with the proliferation, can help to handle spelling errors and management of large numbers of XML files. I think working with XML can be quite painless today, if you have the right tools.