directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Toward 2.0...
Date Wed, 18 Mar 2009 00:30:13 GMT

>> Ok. Today, I spent something like 5 hours trying to get some new 
>> classes injected into LdapService, and make them work nicely with 
>> xbeans. So far, it's a plain failure.
> And your requests for help and complaints about specific problems are 
> where?
> It was a long time ago but 5 hours was the same order of magnitude to 
> the time it took me to convert everything to using xbean-spring (and 
> this was my first use of it).  So I wonder if your problems are due to 
> some small factor that I considered too obvious at the time to 
> document.  From the point of view of just having written something I 
> often think its really obvious how it works, and then a week later 
> spend a lot of time puzzling out what I did :-)

As usual, I tried first to get it working by myself. It may sound quite 
arrogant, but if I can't make it work, then I see no reason why the 
average joe programmer can. If it were so damn obvious, then I must be a 
total arse... (which is still an option, at this point ;)

What fool me totally is that each single time I tried to understand the 
way it works, it always a real pain in the back orifice. Typically the 
signal of bad implemented techno to me...

>> I will be very clear : if we are to continue with xbeans+spring, I 
>> will -1 the release. This is absolutely not mature, cryptic, 
>> unusable, undocumented. In other words, it recalls me Maven 1.
>> Unless xbeans reach another level of stability, I want it out of the 
>> configuration. I'm fed of this piece of garbage.
> Not sure what you mean by stability.  Xbean-spring hasn't been updated 
> in a long time, what it does it seems to do just fine.  Undocumented I 
> can't argue with, but activemq seems to be pretty happy with its 
> current implementation.
Ok, stability is a bit too much.
> I'll happily agree xbean-spring is pretty terrible, but its better 
> than anything else I've seen anyone use.

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.

Even if the previous Spring conf with the 500 char longs lines was 
impossible to read, at least, you were able to knwo exactly in which 
package you can find a class.

So xbeans seems to me like aspirin when you have a cancer (the cancer 
being Spring) : it does not cure, and your stomach hurts...

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 !

PS : I'll be pleased to share a beer or two with you David next week !

cordialement, regards,
Emmanuel L├ęcharny

View raw message