Hi,
As you know, 1-2 months ago, when Tomcat3.2 was frozen, I started to work
on all the long-delayed things that were too "dangerous" to implement in
tomcat3.2 time frame ( the list is at the end ).
Most of that has been implemented ( I sent quite a few mails in addition
to the normal CVS commits describing what's done ). The result is ( IMO
) pretty good, but as expected the code have many bugs ( after you read
the lists of changes, you'll understand why :-)
Unfurtunately, I had far less time than I expected, and the release of 3.2
took far more than I believed. A big thanks to Larry, Nacho and all the
other who fixed so many bugs during the last months, sorry I was unable to
help ( I do have a job and it eats a lot of free time ). I tried to at
least touch the targets and implement the features that were on my
list for far too long.
Tomcat3.2 had a large number of bugfixes that were not incorporated
in 3.3, and 3.3 has a probably a (possibly large) number
of new bugs resulting from the big changes and refactoring.
Now, that I have a bit more time ( I hope :-), I can start spending
more time working on tomcat. There are 2 possible ways to do that:
1. In the current "main branch", incorporate all the fixes from tomcat3.2,
plus fixes for the new bugs.
2. Start with tomcat3.2, and re-do all the changes.
My preference is toward 2 - even if it will probably take a longer
time. I think this is the normal "evolution", i.e. building on top of the
stable release. Because of the long release cycle 3.3 and 3.2 are out of
sync, and I don't want to loose any of the "evolutions" and fixes that
happened.
Regarding the changes that happened so far in 3.3 ( and will have to be
re-implemented if we go with (2) ) - I have a list ( probably incomplete
).
Most of them were sent as proposals before - you can send feedback again.
The goal is of course to continue the evolution and produce a better
servlet container, and also to prevent a fragmentation - I'll try to be as
flexible as possible and let any "controversial" item at the end. As
usually, if you want to -1 any of the changes, I'm sure you'll provide a
better solution and volunteer to implement it :-)
( this mail is related with the development of tomcat3 - it has nothing to
do with other servlet containers and designs - it's just a plan to
continue and enhance the current jakarta-tomcat servlet container. !)
CHANGES 3.3
=================
CORE
- Only one type of Interceptor - remove the separation between Context/Request
Interceptor
- Use introspection to detect the hooks implemented by an interceptor, call
only the interceptors that are implementing the hooks.
- Added handleError hook, refactoring/modularization of error handling - it
is now implemented by a module that can be changed ( see Larry's requirements )
- Added documentation and code to enforce "states" and the order in wich the
hooks are called based on tomcat and context state. For example addContext()
can't be called before tomcat is initialized ( all engineInit done ), etc
- Optional separation of tomcat class loader and webapps classloaders,
similar with Catalina's
- Rewrite of class reloading, the check for expire is no longer done per/request,
but in a background thread. Added DependManager, that allows checks for all
resources, not only classes and works with any class loader ( including
URLClassLoader )
- use of URLClassLoader if JDK1.2 is used ( faster, more secure )
- removal of all deprecated methods and calls
- more documentation
- removal of ServletLoader interface, it's functionality is already provided
in interceptors
- insure org.apache.tomcat.core and facade are layered and remove all spaghetti
calls between layers.
- rewrite of ServletWrapper, separate base ( core ) functionality from the
jsp and servlet-specific.
- removal of ServletConnector, it's functionality can be provided in standard
interceptors. By using normal interceptors a Connector can be better configured
( no more <property name/value /> ), and it can affect all request processing
stages ( to allow future server-based authentication, more performance, etc )
- Move back to the original Request/Response base classes instead of interfaces.
The interfaces were introduced in an effort to merge with Catalina ( by using
common interfaces), but it's a 2-sided process.
- Removal of FacadeManager - it's not needed as the same functionality can be
provided by Interceptors ( to plug the facade ) and simpler mechanisms to
access to internal and check "trusted" apps.
- consolidation of error messages in tomcat.res, consistent with other
apache projects ( and simpler to maintain )
- Removal of Constants - each object will store it's own constants
( tomcat name/version -> ContextManager,
request attributes -> Request, context attributes -> context,
static file resources -> StaticInterceptor, etc ). This also
prevent future inconsistencies ( most of the Constants are not used
in 3.2 anyway )
- Make the "Buffer" a top level element, remove
BufferedInputStream/BufferedOutputStream.
That allow a big increase in performance and allow future improvements by eliminating
multiple "copy" and better reuse of objects.
- Refactoring for all connectors - use more Interceptor features, separate the
tomcat-specific code from the protocol-specific code ( for possible future reuse )
- Use of MessageBytes for all request components
- major simplification of the overal design - fewer and simpler "contracts"
( Interceptor, 6 core objects ) instead of ( Interceptor, Loader, Connector, 12
core objects ), real layering ( instead of spaghetti ), almost all functionality
is now in modules ( like Apache !)
- refactoring of session - use Interceptors for full access to all request
stages, keep tomcat-independent code separated and reusable.
UTILS
- consolidation/refactoring of all tomcat-independent and general-purpose/
reusable code into org.apache.tomcat.util.[log, etc ]
- new utils
BUILD/STARTUP
- generate separate jar files for each component ( utils, core, facade, modules )
That insures the layers are properly separated, utils can be reused.
- use JDK1.2 Main-Class: and a custom starter - deprecate the shell/bat
scripts and use java to process arguments, guess tomcat home, etc
PLANNED ( not yet implemented )
- the EncodingInterceptor that uses MessageBytes and find the right charset
- Use custom-code for Parameters, Cookies ( faster data strucures, like in
MimeHeaders )
- Merge of all modules -> org.apache.tomcat.modules.[config,server,request,etc]
instead of org.apache.tomcat.context/request
- A new configuration mechanism that deals with virtual hosts, allow simpler
installation and configuration for contexts
- Improve Nacho's per/context interceptors, allow "profiles" ( sets of interceptors
that are shared by multiple contexts )
- removal of helpers - use either util ( for tomcat-independent, reusable
functionality,
or Interceptors for tomcat-specific code )
-------
Costin
