directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Why I think Spring + xbean is wrong ...
Date Wed, 05 Mar 2008 22:38:29 GMT
Hi guys,

first, I want to say that it's not a rant in any way.

Straight to the point now.

I was trying to run the Studio to open the latest version of the ADS 
configuration file (server.xml). I got a blatant NPE. Of course, one can 
blame the Studio code which is not defensive enough (fair enough). But : 
the problem is that we are expecting a certain structure for this 
server.xml file, which has changed quite a lot lately. Because we are 
using a Sax parser to parse it (eh, no other way, as we don't want to 
instanciate the beans).

The main issue is that one would have prefered to load the beans 
directly from the Spring structured file, but there is no way to do that 
(beans get instanciated as soon as they are loaded). The way the server 
is built, and more important, the way the configuration is written, 
leads to a real problem : the Spring configuration launch the server, as 
the beans are immediatly instanciated.

So there is no other way but using a hand drafted XML parser...

Could have it been done better ? I think so.
The first thing would have to decouple the configuration from the 
launch. Laoding configuration should by no mean instanciate the server 
or any function. This is simply dangerous, error prone, and horribly 
painfull when debugging the init process (you have to *know* what is 
going on to be able to decipher the init process, which may change as 
loaded beans can change).

The second thing is that I personally find xbean overly complex and 
really useless. Just because it allows you to use some cool annotation 
into the code, it should not lead developer to hit the wall as soon as 
he tries to understand where those annotations has been added. Now, the 
configuration is spread all over the code, instead of being gathered in 
a single location : the configuration file.

Third, the mapping between bean names and real classes is totally 
masked. If you look at the server.xml file, who is able to say that 
'replicaId' is mapped to the class ? No one, except 
those who *know* that the xbean plugin generates a 1.0 file (yes, 1.0 is 
its name !) somewhere here : 

I do think that we went far too far.

wdyt ?

cordialement, regards,
Emmanuel L├ęcharny

View raw message