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
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.
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
called...
Is that an unreasonnable expectation ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
