tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Thu, 06 Jan 2000 04:14:34 GMT wrote:

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

As Costin is well aware (we've discussed this more than a couple of times :-),
we agree on many things and disagree on some others.  The point of this reply
is to elicit comments from the remainder of the Tomcat community on what the
desired next steps in the development process are.

> 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
> and
> 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_
> milestones.
> 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.

Here is the crux of the differences between Costin's suggestion and my
preferred approach:  I do not suggest that we build the Tomcat.Next interfaces
on top of *any* existing Tomcat code.  Instead, I advocate that we refactor
and rebuild it.  The existing code base is functional, but it has a lot of
kludgey cruft in it, and almost no comments -- not my idea of a satisfactory
basis for a high quality servlet container.

The experience I had with Apache JServ was instructive in this regard, because
the same approach was taken -- I started from scratch on the package and class
organization.  However, about 75% of the existing Apache JServ 1.0 code found
its way in to the new environment -- it was just reorganized.

If you take the "refactor" approach, there is no reason in my mind to avoid
starting on a Tomcat.Next branch immediately (probably labeled TOMCAT_4_O_DEV
or something like that).  The parts of the code that Costin wants to
reorganize are absolutely in need of being cleaned up -- but on the 3.x path.
It's going to take a while to do a complete enough major release on the 4.x
path, so I would not be surprised to see a 3.1 and perhaps even a 3.2 release
on the current code base.

But I do not see any reason to wait before getting started.

> I know it would be easier to just create a 4.0 branch and start with the
> new
> 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.

I'm not sure we can agree (although we can of course respect each other's
viewpoints).  But we need to be honest about what really happened.

(1) No developer from the then-current Apache JServ developer team, other than
me, was particularly interested in working on it.  Everyone else was off
working on other things (Cocoon, XML, Avalon, Village/Town/Turbine/ECS, and so

(2) Interest in Apache Jserv 1.1 died the day that Jakarta was announced.  I'm
one of the chief ones who lost interest in it, but by no means the only one.
It was obvious that there was never going to be a next-generation release of
Apache JServ.  And that's actually a good thing  (Jakarta is obviously the
better long-term path).  The only really bad part about the whole deal was how
long it took between the initial announcement and when the Tomcat code was
actually made available.  (If it had been a few weeks longer, I wouldn't be
here -- I was nearing the end of my patience).

(3) Anyone who still uses Apache JServ for new development (and thereby limits
themselves to the features of the 2.0 servlet API) is going to have to rewrite
their applications.  I've got existing apps running on 1.0, and I appreciate
the bug fix support that is still going on, but anyone who builds new apps on
this platform is not looking very far ahead.

> 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 that this is the biggest single problem area in the current code base.

> 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

However, I don't think that trying to build a component shell (based on the
proposed Tomcat.Next interfaces) around the current code base is a good
strategy.  More effort than necessary will be consumed adapting between the
assumptions of the new model and the existing code -- and this also translates
into performance problems as you add adapter layers.

> BTW, the model is almost identical with the alghoritm used by Apache -
> with
> - 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.

That's definitely an advantage I hadn't thought about, but it is real.  You
don't even need to have "developer" and "production" versions of the code base
-- if you are willing to experiment, you just configure in an Interceptor that
replaces the functionality of the existing code and try it out.

> 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
> architecture
> before the end of the month.

Go for the commits.  I'm all in favor of it.

As before, I have no problems at all continuing to improve the current code
base.  I will even help out if you want to divide up the work.  However, that
should not stop beginning on a 4.x tree, based on the new architecture, right

What do all the other Tomcat interested parties think?

> Costin


View raw message