directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Why I think Spring + xbean is wrong ...
Date Sat, 08 Mar 2008 01:51:44 GMT
David Jencks wrote:
>> 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.  
This is the (break)point : to do that, you have to know which 
constructor to add a breakpoint to. So you have to open
1) The server.xml file
2) The 1.0 containing the mapping between bean names and class names
3) All the constructors
> How is this different from having a configuration data object separate 
> from the component?
You will have to put one single breakpoint, and then step into the code.

>> 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 components.
> 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 think that you sum up pretty well what I wanted to express... I 
personally favor (2) because it separates the concerns :
- the way we describe the configuration
- the way we load the configuration
- the way the server use the configuration
>> 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.
Yeah, may be I was not explicit enough... I can see that there are some 
good approach, like modello (seems simple), EMF (way too complex for me, 
but seems to solve my problem too), and even xbean alone.

If I were to repost my initial mail, I would change the tittle to "Why I 
think that Spring is too much when xbean could be enough".

What happened is that I trried to load the latest version of server.xml 
in Studio, and got a NPE (we are using a hand crafted XML parser). 
Obviously, as xbean generates a XSD, we could use Jaxb to do the work.

There are still some remaining issues : either xbeans or modello are 
documentation-free (but when I look at ADS, I would tell myself : "read 
the code, dude" ;). Also modello seems more intuitive, but you have to 
write the model by hand, while xbean is based on annotations.

Anyway, I think that either Spring or xbeans is just bringing some 
confusion, and we could do better. If I had to vote, I would go straight 
for xbeans alone, and leave spring on the side of the road...

Thanks David for the clarifications!

cordialement, regards,
Emmanuel L├ęcharny

View raw message