On Aug 27, 2008, at 2:57 AM, Graham Leggett wrote:
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.
Offhand I don't see why this is better than spring + xbean-spring,
where you get an xsd generated from your classes that your server.xml
plan can be validated against. Furthermore you don't have to write
the code that translates from the xmlbeans objects to the runtime
components, as spring does that part for you. Could you explain?
However if anyone decides to go in this direction I think that using
jaxb instead of xmlbeans, and more particularly sxc, is definitely the
way to go. I think there's a good chance that it would be easy to
make the runtime components actually be the jaxb objects.
thanks
david jencks
Regards,
Graham
--
