David Jencks wrote:
On Dec 3, 2008, at 5:53 AM, Emmanuel Lecharny wrote:
Graham Leggett wrote:
Emmanuel Lecharny wrote:
I can't agree more :/ I already mentionned the fact that using
spring + xbeans was most certainly a bad decision (IMHO), leading
to more problems than solutions...
But this might be just me :)
I completely agree.
The acid test is in the error messages: if a user gets a message
that makes no sense to an end user, then the software is
fundamentally broken. Spring moves lots of stuff that would
otherwise be caught by your compiler (using annotations and other
useful things) into the runtime, and this means end users hit the
bugs, not the developers.
<personal opinion>
I will go a bit forward (and it's not totally related to ADS) : IMHO,
Spring itself is just not the way to go when you want to offer a
solution which is not embeddable only. It does not make sense.
I think that the DI/IOC approach has been stretched far too much.
From a cool techno, very usefull when you want to develop a pluggable
system, that's just fine. Otherwise, it's just following the buzz,
and abusing the idea badly.
</personal opinion>
From the ADS pov, I don't think we will have time to change anything,
unless we spend a serious amount of time defining a better solution
in the next few months. This can be discussed too...
Several people on this list sure like to complain about xbean-spring
but I still don't really understand what they would prefer.
Simple property files fits well in many cases. This what we had before
ads 1.0, and we switch to Spring (and alter to Spring+xbeans) for bad
reasons . (and frankly, xbeans is not really the problem. Spring is.)
IMO the idea behind component oriented wiring frameworks like
xbean-spring is that all the exposed configuration knobs and wires are
things that reasonable users will want to turn or rewire.
This is true _if_ you are working on a plugin oriented system. ADS is
first a LDAP server, second it's embeddable. This is were I don't see
the fit with Spring.
xbean-spring gives you a machine-syntax-checkable way to turn all the
knobs and plug in all the wires. (spring alone is not
machine-syntax-checkable). If you don't like it there are several
possibilities I can think of....
Well, it's a bit like Maven : you like it or not, but at least, it does
the job. The question when it comes to Spring-xbean is much more : is it
usefull for our need ? (I don't want to enter into a long discussion
about the xbean weaknesses, as it's totally irrelevant : I'm totally
confident that with a few more months of work, it's a good companion for
those who are using Spring a lot)
- too many or too few knobs and wires. This means the components
aren't the right size, and is not really a problem with xbean-spring
In other words : design your components with configuration in mind,
regardless what they do. Or at least, don't forget that the
configuration organization will be a direct consequences of your design
choices. *I* just don't like the idea. To me, it's totally orthogonal to
the internal structure of the code. If you have to twist the code to
adapt to Spring+xbean, then that means you are not eligible for using
spring+xbean. Or you should abstract a configuration layer from your
existing code, and do a mapping between this layer and your current code.
- pointy brackets are too sharp and makes my eyes bleed.
Hopefully, you don't sit on an XML file ;)
xml really sucks, but its widely understood, syntax-checkable, and
doesn't require compilation. Wiring in java is very clear but
requires compilation. Groovy builders are really nice but AFAIK don't
really have machine syntax validation.
And property files are also simple, easy to understand, does not need
compilation, easy to comment. Httpd still uses such configuration (sadly
mixed with this sharp brackets ...).
Json is available, too...
Last, not least, injecting the configuration into the DIT is an option.
Some will object that it's complicated, etc, but one big advantage is
that you can access it using LDAP requests (eh, this is a LDAP server we
are working on), and from the Studio POV, this is most certainly
something we want to have, as it permits remote administration using the
existing protocol, not only for ADS, but also for other servers, like
OpenLdap (even if the structure will be different).
Certainly in spring and I think in xbean-spring you can pull some
commonly modified properties out into a properties file. Perhaps this
could be used to supply a "sysadmin-friendly" set of knobs to turn for
stuff like ports and enabled flags along with the full xml
configuration file.
I will add that without David, we would be in an far worst situation, as
he helped us day after day to improve the current configuration. The
problem I have is that I just think that we have picked the wrong
solution at the beginning (and David was not the one to blame, as he
came after this choice has been made). And we have to live with it until
2.0.
May be we should move such a discussion , it would help us to keep
focused on what is currently important, and also will keep the thread
focused on the current server.xml structure (as we won't get rid of
spring + xbean right away...)
Thanks david !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
