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
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
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.
thanks
david jencks
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
