directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: Reducing the complexity/verbosity of default server.xml (and custom configuration files)
Date Wed, 10 Jan 2007 10:37:24 GMT
Thanks for the comments, David.

Don't get me wrong. I may have not be very clear in what seems urgent to me,
and what is not (call it the non english native syndrom).

On 1/10/07, David Jencks <david_jencks@yahoo.com> wrote:
>
>
> On Jan 9, 2007, at 5:29 PM, Emmanuel Lecharny wrote:
>
> > Well, my position is a little bit different. Sure, too much XML suX
> > (ml), but the problem is not that the configuration is huge, it's
> > that we currently don't have tools to manage that (tools = GUI).
>
> I think relying on tools to deal with unnecessary complexity is a
> pretty bad idea.


I don't want to rely on tools. Tools are cool, but when it comes to
administrative tasks, text files are better. When I mentionned tools, this
is just because for new commers, the huge and heavy server.xml file is a
little but a PITA to handle.

Look at jax-rpc for j2ee :-) -- it's IMO totally
> unusable and incomprehensible because the xml is so awful.


That's another good point. It's easy to write horrible xml files (but ,
well, just consider that XML has been horribly abused. Or is it that we have
horribly abused XML ? :) ... Ahh those good old property files !

>
> > But with LdapStudio, I think we might have an acceptable solution :
> > - users who like to click will use it
>
> having tools is definitely good
> > - users who prefer vi and long text file will favor xml files :)
>
> bad xml will drive everyone away, as-simple-as-possible xml will let
> everyone understand what is going on.


That's right. Having a click&paste tool won't fix the bad XML :)

>
> > However, there are so much things in the server.xml file which
> > could be defaulted, that it might be a good idea to spend some time
> > on this subject. I don't really see the point of having all the
> > intercptors exhibited here. Maybe we can default those guys...
>
> defaults are good....
>
> We need some kind of xml, so I think devoting a reasonable effort to
> making it really clear, simple, and expressive is a good idea.  I
> haven't used it myself but the xbean stuff sounds really good from
> what I've heard.


The problem here is that we have followed a path where we started with
property files, then switched to Spring configuratio files, and we are still
thinking about OSGi. So consider the spring based XML file as temporary.
Alas, temporary solutions are often there for a long long time.

I would favor a simplification of the server.xml file, where default values
are removed, and with sub-files for, say, partition. I find it a little bit
complicated to handle many partition configurations in one big single xml
file !

Now, we have some other urgent things to handle, like Schema refactoring,
ugly bugs and pending releases.

I would like to postpone the server.xml refactoring for the next two months,
but definitively, we need this refactoring to occurs before 1.6 version.

-- 
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message