directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [server.xml] Discussion
Date Wed, 03 Dec 2008 18:24:52 GMT
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



Mime
View raw message