On Tue, 24 Apr 2001, Brad Cox wrote:
> >In 3.3 we package all the tests as self-contained wars, and the admin has
> >a web-based runner - but it needs more polishing to make it really easy to
> >use.
>
> That's roughly how I meant for a gui to work. A few text boxes for
> options every novice must touch and run the tests automatically on
> save. Novice-only stuff to make sure it runs out-of-box; eexperts
> will dicker the config files directly.
I fully agree - the /admin provides few informations and services, but
it's user interface is very bad ( and not only from a graphical point of
view ), and incomplete.
I do add new pages and features - every time I have some time - but it
needs much more.
Probably someday I'll start a major refactoring for /admin - at least
separate the "server side" and the "ui", clean up the taglibs, etc.
For a non-web-based GUI it should be possible to control tomcat via URL
requests ( or direct calls ).
> >Regarding the configuration complexity - the main problem is the fact that
> >in few cases the module order is important ( this is true for Apache 1.3
> >also, and Apache2.0 improves a bit with the new "position" parameter).
>
> This may be a big problem, but its not the main one for mortals. XML
> validation only ensures that the configs are syntactically correct.
> Without semantic validation (like your test suite could provide),
> tomcat reports common errors, mispelling a context name, classpath
> problems, etc, by throwing NullPointerExceptions and the like from
> very low level code. Usually the stack trace provides no way of
Agree - but remember this is open-source, with all it's benefits and
problems.
It would be nice to have better error messages - if someone would
write the code ( or at least more docs ).
Probably a good solution would be to stop using server.xml as a
user-modifiable config file, and work on a GUI that will expose only
a controled set of options.
( advanced users will still edit server.xml, but most users shouldn't
touch it ).
One way or another - tomcat is a collection of modules, like apache. The
config file is not setting some tunnable parameters, but it's wiring up
the whole tomcat. It has a lot of power - but it's probably not the best
thing for users.
> >Most of the effort has been put into the lower-level architecure and
> >modularity - and not in individual modules. The idea is that in time we
> >can rewrite individual modules ( for example the mapper is a big target
> >for optimizations, etc ), and improve various spots.
>
> That's about repairing/redesigning the bowels of the mine. I'm saying
> tomcat needs some work on the sales office. Its not either-or; both
> need work.
Yes, but I can hardly find time for one. I would love to work on both -
but so far I coulnd't find people to help on the /admin, and I'll
not start it alone.
( well, Larry and few others helped a lot - but he seems to have even less
free time than I have ).
> >Fact is - we do improve - and that's what matters ( for me ). I don't
> >think anyone claims the first versions of apache were easy to install ( or
> >even the latest ).
>
> Indeed! And thanks for listening!
Well, thanks for the feedback - and even more thanks if that leads to some
code contributions.
Costin
