directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Partition configurations [was Re: [CONF] Apache Directory SandBox: Draft - ... ]
Date Mon, 17 Nov 2008 10:46:45 GMT
David Jencks wrote:

Hi David,

I will try to coo my yesturday temper : I was a bit tired... :)
> On Nov 16, 2008, at 5:14 PM, Emmanuel Lecharny wrote:
>> David Jencks wrote:
>>> I can't say I regard xbean-spring as an ideal solution, but I don't 
>>> really understand why people think its any harder to use than plain 
>>> spring.
>> Because it is !!! Instead of having a single file where you have all 
>> you need to get connected to the source, you have to permanently go 
>> back and forth from conf to source, guessing what could be the class 
>> associated with a name in the conf file, and what can be the 
>> attributes you can configure.
> I understand that figuring out what class relates to what element is 
> more difficult at the moment with xbean-spring.
It's always a balance : either you have a lightweight XML configuration 
file, and I must admit that Spring carries a lot of dead weight with all 
those packages before the class name, so having a simple name instead is 
an improvement, or you have a heavy config file, but it's easier to 
understand what is initialized when you start the server, as you have 
all the information needed.

The problem is that ADS is about 2500 classes, and it's pretty hard to 
know where you can find a class by its name (grep is not an option ;)

> IIRC the default is to use the java package in the namespace and the 
> class name as the element name.  I thought lots of namespaces would be 
> harder to use than a single namespace, maybe this was not a good 
> decision.  Quite possibly it would be better to have a few packages 
> with the configurable objects and namespaces for each.
> I'm confused about your claim that it's harder to figure out which 
> attributes you can configure with xbean-spring than with plain spring.  
Let me explain : as we have a pretty deep inheritance tree, you have to 
check for all the setXXX() in all the parent's classes, which is a bit 
painfull, IMHO. What would be _way_ better is to describe the attributes 
with annotation, instead of letting xbean extrapolate them using 
introspection. At least, if you don't have such an annotation present, 
then it will default to introspection, but otherwise, if a 
@xbean.arguments( "attr1, attr2, ..." ) is present (or whatever other 
solution), it will help a lot the developpers.
>  Without looking at the xsd or the class I don't see you have any way 
> of telling in either case.  If you look at the class its pretty 
> obvious in either case.  With xbean spring you also get a schema that 
> most editors will use to provide context-sensitive suggestions about 
> what elements or attributes are allowed: this is not possible with 
> plain spring AFAIK.  If you can explain further I'd like to understand 
> what the problem is.
I agree that plain Spring does not help you to do that. I hope that I 
explained what I had in mind in my previous comment.
> <snip/>
>> well, I don't have any favorite XSD editor, and I don't have time to 
>> absorb the messy XSD syntax. That's one of the reason I find it 
>> overkilling.
> Xsds are a pretty horrible language, but I admit I don't find them 
> that hard to understand.  
I have spent a hell of time on compilers, trully, BNF is a beauty. XSD, 
not so much (this is a direct reference to Borat ;)

To recall a reference to some comment you can find in Gnu preprocessor :

  /* Pre-C-Preprocessor to translate ANSI trigraph idiocy in BUF
     before main CCCP processing.  Name `pcp' is also in honor of the
     drugs the trigraph designers must have been on.

XSD must be one of the latest cool drug the guys who invented XSD must 
have been on when they drafted it... I must admit that DTD was much 
worst, but at least, it was so disgusting that you had no chance to 
become an addict :)

Seriously, XSD is crap... Even if it's not _that_ complex :)
> But with most editors (idea and I'm sure eclipse) 
I didn't found a free and easy to use XSD editor on eclipse so far... 
And trust me, I tried a bunch of those crappy SF drops...
> if you tell the editor about the schema it will provide validation as 
> you type and context sensitive hints about what is allowed.  I find 
> this a lot easier to use than having to consult the class (or the 
> schema) to find out what is allowed.
Well, if you can read an XSD file, sure. IMHO, XSD is only valid when 
you want to validate a XML file, and only when it's handled by a 
computer, not by human being. Eh, I was used to write code using direct 
hexadecimal on my first Z80 or 6502 computers, but I don't think it fits 
well in term of productivity :) XSD is a bit like assembly to me...
>> May be it's just me, but from discussions I had with other projects 
>> as well, XBeans may be a cool techno, but certainly not something 
>> which makes developpers life easier. IMHO.
> I hope I'm not being too much of a nuisance here.... 
Nah, don't worry ! I'm just whining ;)
> I don't think xbean is the last word in configuration, but I am 
> leaning towards jaxb based xml <--> configuration object solutions 
> which have the same basic features as xbean spring so I'd really like 
> to understand if there are fundamental problems with this kind of 
> approach of having an xml domain specific language for component 
> configuration.
I understand you approach, David. It makes a hell of sense, as 
manipulating XML files to make them closer to the code is now necessary 
because of IoC. And I also agree that those damn <package 
name>+.<className> are just a PITA.

Here is what I think : Spring, and all those IoC/DI stuff are just 
totally over rated. People tend to think that by defining their system 
using beans is the ultimate way to go, as we weren't able to send a man 
to the moon without all those craps... This is just a nonsense. Either 
you have a plugable architecture (ie, JDBC drivers), or a Container 
based system, or you don't. Usually, it's a mix. When it comes to ADS, 
we have many plugable modules, like authentication systems,  
SyntaxCheckers, etc, but I find this IoC thing far too complicated for 
what we need. Either from the user POV (because it forces the user to 
manipulate a pretty verbose file), but also from the developper POV, as 
you simply can't anymore step into the initialization phase, unless you 
put a number of BP into your code.

IMHO, Spring is one of the worst system ever, because not only it's 
useless in 99,9% of the time, but also because it spreads myths like "it 
makes your life easy". I may be wrong, of course, but I'm following the 
Spring buzz since 2001 (or 2002, I don't remember), and I can't stop 
thinking that it will die sooner or later. The simple fact that you need 
to design XBean to ease the pain Spring is introducing is just another 
nail in the coffin...

Thanks David !

cordialement, regards,
Emmanuel L├ęcharny

View raw message