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
www.iktek.com
directory.apache.org
