tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Wed, 05 Jan 2000 19:55:18 GMT
> Please consider this a proposal for a major remodel of the
> org.apache.tomcat.core package.  Because it will require such
> significant changes (both in the code and the configuration files), I
> would suggest we consider this the basis for a new major version of
> Tomcat (4.x), so that bug fixes and enhancements can be made
> simultaneously on the 3.x tree for the current version.


I agree with most of your proposal - I disagree with some details ( as you
know).  I don't want to discuss this now - but the strategy we should use
to make the re-model of tomcat.core.

I am very much opposed to any "major" change that will brake tomcat in more

than a place. Instead of a major version that will have all the features
changes you mentioned, I would prefer a number of minor changes that will
make incremental changes. This will allow people to contribute and comment
on each step, and we should be able to have frequent and _usable_

Also, we should add the interfaces you propose after we have all the
implementation feedback and comments -  and _after_ we clean up
and have a working implementation.

I know it would be easier to just create a 4.0 branch and start with the
set of interfaces and build everything around it - the way JServ1.1 branch
worked. IMHO, the biggest problem of JServ 1.1 was exactly that - even
if it has a great design, people are still using JServ 1.0.

Please, let's agree on this issue.

The biggest change ( and the first we should do ) is to change the current
request processing model ( Context/Container/RequestMapper/LookupResult/
ServletWrapper/RequestDispatcher) to a modular and cleaner model.

I agree on using something like Interceptors for this - I'm working on that

since Nov., and I would like to commit the changes this month, so the
rest of your proposal ( with some changes I hope :-) can be implemented

BTW, the model is almost identical with the alghoritm used by Apache -
- module==interceptor,
- request_rec==Request+Response,
- per_dir_config == Context ( or Container)

Same thing is used by NSAPI and ISAPI - and I guess their internal
model is similar.

To add to your list of advantages, using Interceptors ( maybe with another
name - Handler like in Apache maybe ?) will allow us to keep a stable
implementation ( the current code ) while experimenting with faster
alghoritms. As soon as we finish the second step ( component configuration
we'll be able to develop in all directions while keeping everything stable.

If we agree on this, I that we start committing changes to the core package
in order to have at least a primitive version of Interceptor-based
before the end of the month.


View raw message