directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Why I think Spring + xbean is wrong ...
Date Sat, 08 Mar 2008 00:48:31 GMT

On Mar 7, 2008, at 2:27 AM, Emmanuel Lecharny wrote:

> Stefan Zoerner wrote:
>> Emmanuel Lecharny wrote:
>>> ...
>>> I do think that we went far too far.
>>> wdyt ?
>> Let me first say that I really liked the idea of making  
>> configuration of ApacheDS simpler form a user (e.g. administrator)  
>> perspective. The xbean approach did a good job here, the files are  
>> shorter and more expressive.
> I will temper my initial mail : xbean has some advantage : it  
> generates a XSD. But the indirection is still a PITA...
>> Unfortunately, some ports of the configuration are comparable  
>> complicated to the 1.0 pure Spring world (or even more complex).
>> For instance:
>> ...
>>     <!-- The desired quality-of-protection, used by DIGEST-MD5 and  
>> GSSAPI.  -->
>>     <saslQop>
>>       <value xmlns=" 
>> beans">auth</value>
>>       <value xmlns=" 
>> beans">auth-int</value>
>>       <value xmlns=" 
>> beans">auth-conf</value>
>>     </saslQop>
>> ...
> It can be replaced by :
> <spring:beans xmlns:spring=" 
> 1.0"
>              xmlns:s=" 
> beans"    <!-- Added NameSpace declaration -->
>              xmlns="">
> ...
>    <saslQop>
>      <s:value>auth</s:value>
>      <s:value>auth-int</s:value>
>      <s:value>auth-conf</s:value>
>    </saslQop>
> Much simpler ...

very true :-)  why didn't I do that ??
I think I was hoping to figure out a solution all in the apacheds  
namespace and never got back to looking for it.
>> The question I asked myself when xbean was introduced: Isn't it  
>> possible  to use our own namespace and use pure Spring 2.0  
>> functionality for that to make configuration easier? This has been  
>> done with transactions, AOP etc. in Spring itself.
>> Perhaps we can obtain a comparable result with native Spring  
>> features, and avoid the dependency to xbean.
>> extensible-xml.html
> May be... This has to be explored.

Definitely worth looking into.  I haven't :-)  I've heard rumors that  
it is not as capable as xbean-spring but being built-in is pretty nice.

>> Whether this will conflict with Emmanuel's requirement to make  
>> configuration easier to parse/edit with Studio -- I have not  
>> thought about that yet.
> The thing is that we have one major problem with Spring + xbean :  
> when you want to debug the server, from the initialization point,  
> it's a real PITA, as the flow is not know unless you have the  
> server.xml and the 1.0 mapping file open on the same screen (and I  
> don't have a 40" screen on my laptop ...).

I'm not sure yet why this is a problem.  I'd expect you'd put  
breakpoints in the constructors of all the components and you'd see  
in your debugger what all the parameters are.  How is this different  
from having a configuration data object separate from the component?

> Another point is that we have mixed configuration laoding and  
> initialization, which is, from my POV, a bad mistake.

OK, I think this might be the big question here that could determine  
how to proceed.  I think there are kinda 2 extremes of points of view  
as to what is "good":

1. we just have components that do stuff, and the framework directly  
wires them up and then they are the running server.  As far as  
complexity of the working components this is obviously (at least to  
me :-) the simplest possible solution and good design.  However,  
there's no way to look at a java model of the configuration without  
having a running server, and there may be a mismatch between the way  
you want to configure the components and the structure of the  

2. we have a java data-object model of the configuration, and some  
way of taking such a model and pushing the info into components and  
starting the components.  This has lots more objects than (1) but may  
possibly result in easier configuration of the "important stuff"

Then there are lots of ways of mixing these up.  I don't think  
there's any right answer.  I do think (1) tends to be simpler code  
but harder configuration.  IMO Spring is definitely oriented towards  
supporting (1).  With the xbean-spring generated schema we could  
easily do a version of (2) where we generate data objects from the  
schema using jaxb and add a lifecycle "start" method to create the  
component.  This could eliminate spring entirely.  Then we could  
tweak the schema to make it easier to configure stuff if we wanted.   
I haven't grasped the EMF approach well enough to see exactly where  
it fits into this spectrum of choices.

> I know that some will disagree with me, and it's fine, as soon as I  
> just express some frsutration I have. That does not mean I'm  
> right ! But I want to make it clear that if I'm frustrated with  
> what we have, then there is some chance that new committers will  
> find it frustrating too...

I wish I understood better what you are frustrated with..... trying  
to configure the server in studio is certainly something that is not  
well supported, but I don't quite get the other stuff yet.

david jencks

> Thanks Stefan !
> -- 
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message