Emmanuel Lecharny wrote:
That's the main issue... Xbeans is trying to alleviate the pain it is to manipulate class names in a Spring file. As I already said, it creates a decoupling which is painfull, as you have no clue about what is what in the Spring file when you have decoupled those two parts. We have more than 2500 classes in Directory (not counting Studio), and even after 5 years working on the project, I can't easily remember where all of them are located.
The name of the principle you are currntly violating by using Spring is called the "Don't repeat yourself" principle:
http://en.wikipedia.org/wiki/Don%27t_repeat_yourselfBy storing class names in two places (the Java class file, and the Spring bean definition XML file) you are adding 2500 different opportunities for the classes and spring configs to go out of sync.
And there is nothing in the class to suggest that a spring bean is somehow relevant, making refactoring impossible, and that kills code.
To be frank, and we discussed that ad nauseam with Alex, using Spring was one of the biggest mistakes we made. We don't need Inversion of control/Depenency Injection/whatever Fowler call it. This is useless in our case. What we need is a configuration which can be loaded at startup, and that's it. what we had before (a property file) was just plain ok. OpenLDAP is now storing the configuration in the DIT, and it works perfectly well.And if we don't want to go back to a property file, or config in the DIT, then JSON can be an intersting option. Everything but this infamous brackets all over the configration !!! Die, XML, die !
When I use XML as a config, I define that config as an XSD, throw the XSD through xmlbeans to write all the parsing code for me, and then I make sure the config file is properly validated on load.
If the end user does something wrong, the end user gets proper error messages telling them what they did wrong, and what line they did it wrong on.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
