On Mar 7, 2008, at 2:27 AM, Emmanuel Lecharny wrote:
Stefan Zoerner wrote:
Emmanuel Lecharny wrote:
...
I do think that we went far too far.
wdyt ?
Let me first say that I really liked the idea of making
configuration of ApacheDS simpler form a user (e.g. administrator)
perspective. The xbean approach did a good job here, the files are
shorter and more expressive.
I will temper my initial mail : xbean has some advantage : it
generates a XSD. But the indirection is still a PITA...
Unfortunately, some ports of the configuration are comparable
complicated to the 1.0 pure Spring world (or even more complex).
For instance:
...
<!-- The desired quality-of-protection, used by DIGEST-MD5 and
GSSAPI. -->
<saslQop>
<value xmlns="http://www.springframework.org/schema/
beans">auth</value>
<value xmlns="http://www.springframework.org/schema/
beans">auth-int</value>
<value xmlns="http://www.springframework.org/schema/
beans">auth-conf</value>
</saslQop>
...
It can be replaced by :
<spring:beans xmlns:spring="http://xbean.apache.org/schemas/spring/
1.0"
xmlns:s="http://www.springframework.org/schema/
beans" <!-- Added NameSpace declaration -->
xmlns="http://apacheds.org/config/1.0";>
...
<saslQop>
<s:value>auth</s:value>
<s:value>auth-int</s:value>
<s:value>auth-conf</s:value>
</saslQop>
Much simpler ...
very true :-) why didn't I do that ??
I think I was hoping to figure out a solution all in the apacheds
namespace and never got back to looking for it.
The question I asked myself when xbean was introduced: Isn't it
possible to use our own namespace and use pure Spring 2.0
functionality for that to make configuration easier? This has been
done with transactions, AOP etc. in Spring itself.
Perhaps we can obtain a comparable result with native Spring
features, and avoid the dependency to xbean.
http://static.springframework.org/spring/docs/2.0.x/reference/
extensible-xml.html
May be... This has to be explored.
Definitely worth looking into. I haven't :-) I've heard rumors that
it is not as capable as xbean-spring but being built-in is pretty nice.
Whether this will conflict with Emmanuel's requirement to make
configuration easier to parse/edit with Studio -- I have not
thought about that yet.
The thing is that we have one major problem with Spring + xbean :
when you want to debug the server, from the initialization point,
it's a real PITA, as the flow is not know unless you have the
server.xml and the 1.0 mapping file open on the same screen (and I
don't have a 40" screen on my laptop ...).
I'm not sure yet why this is a problem. I'd expect you'd put
breakpoints in the constructors of all the components and you'd see
in your debugger what all the parameters are. How is this different
from having a configuration data object separate from the component?
Another point is that we have mixed configuration laoding and
initialization, which is, from my POV, a bad mistake.
OK, I think this might be the big question here that could determine
how to proceed. I think there are kinda 2 extremes of points of view
as to what is "good":
1. we just have components that do stuff, and the framework directly
wires them up and then they are the running server. As far as
complexity of the working components this is obviously (at least to
me :-) the simplest possible solution and good design. However,
there's no way to look at a java model of the configuration without
having a running server, and there may be a mismatch between the way
you want to configure the components and the structure of the
components.
2. we have a java data-object model of the configuration, and some
way of taking such a model and pushing the info into components and
starting the components. This has lots more objects than (1) but may
possibly result in easier configuration of the "important stuff"
Then there are lots of ways of mixing these up. I don't think
there's any right answer. I do think (1) tends to be simpler code
but harder configuration. IMO Spring is definitely oriented towards
supporting (1). With the xbean-spring generated schema we could
easily do a version of (2) where we generate data objects from the
schema using jaxb and add a lifecycle "start" method to create the
component. This could eliminate spring entirely. Then we could
tweak the schema to make it easier to configure stuff if we wanted.
I haven't grasped the EMF approach well enough to see exactly where
it fits into this spectrum of choices.
I know that some will disagree with me, and it's fine, as soon as I
just express some frsutration I have. That does not mean I'm
right ! But I want to make it clear that if I'm frustrated with
what we have, then there is some chance that new committers will
find it frustrating too...
I wish I understood better what you are frustrated with..... trying
to configure the server in studio is certainly something that is not
well supported, but I don't quite get the other stuff yet.
thanks
david jencks
Thanks Stefan !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
