directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: Why I think Spring + xbean is wrong ...
Date Thu, 06 Mar 2008 02:07:48 GMT
Hey Emmanuel,

I'm going to comment on how EMF solves the issues, which I've done before, but I figured plugging
it in different scenarios might be helpful.  I'll just throw it in as a backdrop...  

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

First EMF would give you the option to model the configuration file using java interfaces,
xml schema, EMF Ecore (XMI) (I'm sure there are all sorts of other means as well now) and
provides very smart tooling
for doing all of this, so that you get real time validation of the model.  
The just generate the corresponding java beans for loading instances of 
server.xml.  They are now completely separate from the server, and should be
queried by the server components as the server is loading and needs configuration

Also Studio, JUnit, or anything else could load server.xml files completely
independently of the server and it's components.

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

With EMF the beans / components would get a reference to the configuration model, thus configuration
is completely decoupled from the beans / components.  So there would be configuration bean
(Focused only on providing configuration information, and other beans focused other concerns).

> 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.
This is a good argument for using EMF I think.

> So there is no other way but using a hand drafted XML parser...

Hang on...EMF.

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

This is what a ton of projects use EMF for.  Complete separation of the 
configuration model from other services.  Core services should source configuration
information from the "Configuration Service", as you are saying.

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

With EMF the XML Schema for the configuration file is it.  It reflects configuration in its
entirety.  Update it and everything else is updated automatically...With the exception that
the components that are customers of the configuration schema change would have to be updated,....Studio
could also use the EMF validation framework to provide informative messages / insight into
what is wrong, in case someone introduced errors into the server.xml file.

> Third, the mapping between bean names and real classes is totally 
> masked. 

With EMF the name of the bean corresponds to the name of the XML Schema element.  Also, annotations
can be used to customize how the model is serialized, although the default xml serialization
very intuitive and easy to read.

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

> I do think that we went far too far.
> wdyt ?
I personally like to manage configuration completely separately from everything else, so I
agree.  Being able to load the configuration separately also makes testing a lot easier in
my opinion.

If ADS used EMF, components could be written and unit tested by themselves.  Another thing
that's really cool about EMF is that you can set model defaults on the XML schema, and these
will be generated into the Java beans, such that if you create an instance of the server configuration,
without actually loading the configuration, it's a valid configuration instance.  This can
now be passed to a new component being written, and the component can be unit tested using
valid configuration data with minimal effort.

ADSConfiguration configuration = new ADSConfiguration();

This is a valid configuration instance.  The server could run on this without ever loading
server.xml.  Thus the same instance can be used for unit testing all the components.

Another benefit that I've mentioned in the past is that using EMF allows a valid server.xml
to always automatically generated, since it's just the new / updated model schema serialized.

- Ole

View raw message