tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Cox <>
Subject RE: ServerSocket not being closed properly.
Date Tue, 24 Apr 2001 19:07:13 GMT
At 9:50 AM -0700 04/24/2001, wrote:
>here are few ideas that can be used for configuration validation, and
>the best ( IMHO ) is to run the sanity test after every change in the
>config file. ( maybe watchdog too ).
>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

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.

>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 
connecting the error with the config error that is causing it. I seem 
to get bitten by a half dozen or so variations on this theme every 
time I install a new release, which involves a week of frustrated 
guessing each time. The only solution I've found is to load the 
Tomcat sources into Visual Age and treating each release as a 
low-level debugging exercise.

>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.

>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!
Brad Cox, Ph.D.;
Phone: 703 361 4751 Cell: 703 919-9623

View raw message