tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: ServerSocket not being closed properly.
Date Tue, 24 Apr 2001 19:49:34 GMT
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 

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.


View raw message