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 Wed, 05 Mar 2008 23:51:02 GMT

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.  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.

> 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.
> 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.
> 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.

> 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.
> 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.

david jencks

> -- 
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message