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
information.
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
org.apache.directory.mitosis.common.ReplicaId 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/apacheds.org/config/1.0
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.
Cheers,
- Ole
