directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: [ApacheDS] [XBeans] [Spring] Any issue with moving to spring 2.5?
Date Wed, 27 Aug 2008 09:57:22 GMT
Emmanuel Lecharny wrote:

> not only is this complex from the user POV, but from the developper POV, 
> this is a nightmare. I frankly don't like those annotations stuff, plus 
> the fact that the objects are instanciated during the xml file 
> processing is a real burden (and makes the configuration file way too 
> complex).
> I will talk my mind : I think that going for Spring was a big mistake.

I have to agree at this point.

My key experience with Spring is with debugging issues with it. On the 
last major project, virtually all issues that managed to slip past 
continuous integration were caused by mistakes in Spring files, which 
march straight past the compiler and in many cases past the unit tests 
and are found by the end user instead.

The worst problem was a stray 'singleton="true"' that someone had put on 
a bean by accident through some careless cut and paste. It caused some 
financial reports to return subtly different data when the reports were 
repeated, and took over a month to find and fix. The end result was a 
whole host of assertions in the code entitled "dodgy stuff that Spring 
might do", and it aged us by years.

> Now, what can we do ? I think that the way to go is to have the 
> configuration in the DIT, with LDIF based configuration files (like 
> OpenLdap has).

What I have been doing with config files is defining the structure of 
the config files with an XSD, and then reading in the config file at the 
outset using xmlbeans autogenerated from the XSD.

Like Spring, your config files are in an XML format, and like Spring, 
you end up with a set of Java beans that you can query to read your 
config, but unlike Spring, the format of the config file has a fixed 
structure validated against an XSD, and your code is validated by your 
compiler before it hits the end user.

What this gives you is a (reasonably) sensible error message if the user 
makes a mistake in the config file, as you ask xmlbeans to validate the 
file when you read it in.

In addition, making changes is a breeze: Change the XSD, regenerate the 
xmlbeans, wherever you have a compile error, that's where you need to 
change your code to support your new structure.


View raw message