tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: Tomcat, Catalina, and Java2
Date Tue, 11 Jul 2000 05:20:08 GMT
Dave Harms wrote:

> Craig,
>
> > (Prior to that time, the remaining
> > features of Tomcat 3.2 that are not yet supported by Catalina will also
> > be migrated).  Making the Java2 dependency known now lets us start
> > migrating the Catalina code base to Java2 now
>
> Newbie question here, but is all of the Catalina code still experimental,
> i.e. none of it is used in 3.x?

None of the Catalina code is directly used in Tomcat 3.x, although Catalina
has influenced the current design of some Tomcat 3.x functionality.

A very small amount of Tomcat 3.x servlet container code (XmlMapper and a few
utilities) is used in Catalina -- everything else is a "clean slate"
starting-over implementation of a servlet container.

Catalina currently uses the same JSP engine (Jasper) that Tomcat 3.x does.

> What are the fundamental architectural
> differences between Catalina and the current core code? I've been over
> your JavaOne slide show, and it helps a bit, but I'd be interested to
> know more.
>

NOTE:  the differences between Tomcat 3.x and Catalina are primarily
internal, and not directly visible to servlet developers.  That is as it
should be, since they both implement a portable API.

To get a feel for why Catalina exists, you need to go back a little -- to the
code that Sun originally contributed to the Jakarta project (which
subsequently was massaged into Tomcat 3.0).  The code then was a total
disaster from a maintenance and enhancement point of view -- the code paths
that were actually followed when handling servlet requests fit the classical
description "spaghetti code", the Javadoc comments were mostly non-existent
or non-current, and there was no overall architecture documentation.

Catalina grew out of what was going to be Apache JServ 2.0 before Sun
announced the Jakarta code handover.  It's architectural organization is
based around the following goals:

* Clearly defined component-based architecture based
  on Java interfaces.  Tomcat 3.x is moving in this
  direction, but it's not as clearly documented.

* Components are "configure from the outside", using
  normal JavaBeans property APIs.  (True for both
  approaches).

* Component lifecycle support for all components that
  want it, but optional so you don't have to implement
  this if it is unnecessary.  (Tomcat 3.x components deal
  with this in their own individual ways).

* Plug-replaceable components for virtually everything,
  so that servlet container implementors or integrators
  can customize it.  (Tomcat 3.x does this for some
  components, but not all.)

* Extensible request processing, using a well-defined
  mechanism (Valves) that has lower runtime overhead
  than the current Tomcat approach (RequestInterceptors).
  In both Tomcat and Catalina, this technique is used to
  segregate request processing activities -- especially
  optional stuff like container-managed security -- from the
  core functions of managing servlets and their lifecycle.

* Flexible deployment architecture, in the sense that you
  can provide different numbers and kinds of "containers",
  including anything from embedded systems to stand
  alone mini-app-servers to webserver backends, to the
  web component of a full-featured J2EE application server.
  (The people historically working on Tomcat 3.x have been
  mostly concerned with integrating Tomcat with webservers,
  although a modified version of Tomcat 3.0 is used in
  the J2EE reference implementation from Sun).

* Support for integration with the existing APIs of a larger
  server, such as logging and user authentication.  (Particularly
  in the area of authentication realms, Tomcat is getting closer
  to the Catalina approach).

* Abstraction of session management support (including
  optional session persistence and swapping) in preparation
  for building a distributed servlet container in the future.
  (Tomcat switched to an early version of Catalina's code
  for these capabilities, but there are subtle differences).

* Ability to use Catalina as the basis for non-HTTP servers
  (although such servers are unlikely to be built in to the
  standard release).  Tomcat 3.x is only interested in
  serving HTTP requests.

* Performance at least as good as current Tomcat 3.x
  code when released, and capable of being tuned for
  better performance later (especially in non-webserver
  environments, while much of the effort at tuning Tomcat
  3.x has gone into improving its performance when running
  behind Apache or some other web server).

In the year or so since the Jakarta code transfer was announced, Tomcat 3.x
has moved substantially closer to some of these goals (thanks in large part
to the effort of folks like Costin Manolache and Gal Shachor), and the
performance of Tomcat 3.x has been improved substantially -- but there comes
a time in any systems' life where it's time to apply everything we've learned
about building servlet containers to a fresh start.  That fresh start, in the
opinion of lots of folks that have looked at it, is Catalina.

>
> Dave
>
> Dave Harms
> jdev@clarionmag.com
>

Craig McClanahan



Mime
View raw message