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 Thu, 06 Mar 2008 00:14:14 GMT
David Jencks wrote:
> On Mar 5, 2008, at 2:38 PM, Emmanuel Lecharny wrote:
>> Hi guys,
>> first, I want to say that it's not a rant in any way.
>> Straight to the point now.
>> I was trying to run the Studio to open the latest version of the ADS 
>> configuration file (server.xml). I got a blatant NPE. Of course, one 
>> can blame the Studio code which is not defensive enough (fair 
>> enough). But : the problem is that we are expecting a certain 
>> structure for this server.xml file, which has changed quite a lot 
>> lately. Because we are using a Sax parser to parse it (eh, no other 
>> way, as we don't want to instanciate the beans).
> You have me at a disadvantage here as you give no clue why you are 
> trying to programatically understand server.xml without starting the 
> server.  
Simple scenario, as explained before : The Studio tries to open the 
server.xml just because as it carries ADS configuration, it is really 
cool to allow users to manipulate a GUI instead of diving into a 400 
lines XML file... No need to start the server ofr that, isn't it ?
> Without knowing that, its hard to discuss anything intelligently.  No 
> matter what the solution, its easy to come up with lots of scenarios 
> that are difficult using that solution.
Is this scenario enough to justify my need for a simplier solution ?
>> The main issue is that one would have prefered to load the beans 
>> directly from the Spring structured file, but there is no way to do 
>> that (beans get instanciated as soon as they are loaded). The way the 
>> server is built, and more important, the way the configuration is 
>> written, leads to a real problem : the Spring configuration launch 
>> the server, as the beans are immediatly instanciated.
> How is this a problem?  Seems to me like a gigantic simplification 
> over having spring do its lifecycle + apacheds duplicate all the 
> lifecycle work.  I'm personally a believer in constructor dependency 
> injection for components which means that, normally, once the 
> component is instantiated, it's started.  IMO this is good component 
> design so there would have to be an extremely compelling reason to 
> move away from this.
IMO, initialization should be a totally different phase that the 
configuration loading. Coupling those two guys just leads to big problems...
>> So there is no other way but using a hand drafted XML parser...
> Umm, there's a generated schema, so you can also use jaxb or xmlbeans 
> to generate data classes that exactly represent the xml and use them.  
> Hand crafted xml parsers have not been a plausible solution to 
> anything for years AFAIK.
I agree on that (hand crafted XML parsers are just silly, except in 
specifci cases where performance is needed), but why should we generate 
new class when we already have existing classes ?
>> Could have it been done better ? I think so.
>> The first thing would have to decouple the configuration from the 
>> launch. Laoding configuration should by no mean instanciate the 
>> server or any function. This is simply dangerous, error prone, and 
>> horribly painfull when debugging the init process (you have to *know* 
>> what is going on to be able to decipher the init process, which may 
>> change as loaded beans can change).
>> The second thing is that I personally find xbean overly complex and 
>> really useless. Just because it allows you to use some cool 
>> annotation into the code, it should not lead developer to hit the 
>> wall as soon as he tries to understand where those annotations has 
>> been added. Now, the configuration is spread all over the code, 
>> instead of being gathered in a single location : the configuration file.
> I have no idea what you mean here.  AFAIK the configuration is still 
> all in server.xml, although now there is also a schema so automated 
> checking of some of the plausibility of the server.xml file is possible.
everything is possible, but some are just more complex when using such a 
scenario. That's my problem ...
>> Third, the mapping between bean names and real classes is totally 
>> masked. If you look at the server.xml file, who is able to say that 
>> 'replicaId' is mapped to the 
>> class ? No one, except 
>> those who *know* that the xbean plugin generates a 1.0 file (yes, 1.0 
>> is its name !) somewhere here : 
>> apacheds/apacheds-xbean-spring/target/xbean/META-INF/services/org/apache/xbean/spring/http/

> well, it would have been a lot easier to have a separate namespace for 
> each maven subproject, but I thought people would object more to that 
> than having a single namespace.
That won't solve the problem. We now have three places to look at when 
debugging the server :
- the server.xml file
- the 1.0 file (silly name ...)
- and the code.

When I debug a piece of software, I just hate jumping through files like 
that. May be I'm just thinking a little bit too linearly. I like to step 
the code, not to step the code/server.xml/1.0/code/server.xml/.... Too 
complicated for me...
>> I do think that we went far too far.
>> wdyt ?
> I think spring sucks in a lot of ways and look forward to the time 
> when it can be replaced with an extended version of jaxb that can 
> handle constructor dependency injection and factory beans.  Right now 
> I think spring + xbean-spring is still the best balance between 
> expressive configuration and a reasonably functional container.
> If we were willing to abandon all constructor dependency injection and 
> take over the component lifecycle code entirely then we could probably 
> just use jaxb to create all the components.  Dain is also working on 
> some stuff that might allow a switch away from spring.

IMO, Spring is ok if it is limited to loading beans, but not instanciate 
them. There is no need to initialize anything but the data. At the end 
of the day, beans should be plain stupid POJO, nothing more.

If you want to go any further, then just have a simple bean which 
initalize the whole stuff after having loaded all the 
POJO/configuration, taht's my point. I want to be able to put a 
breakpoint in the code where the POJOS are read, being able to check 
that the configuration is now present in those data structures, and then 
being able to step the initialization process in a debugger without 
having to put breakpoinst all over the code to know what's going to be 

Is that an unreasonnable expectation ?

Thanks !

cordialement, regards,
Emmanuel L├ęcharny

View raw message