tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Next release
Date Wed, 12 May 2004 06:12:33 GMT

"Remy Maucherat" <> wrote in message
> I feel like starting working on the possible new codebase for Tomcat,
> now that Tomcat 5 is more or less stabilized. I have a few obvious
> items, but while a lot could be done to make the code more modern, it
> wouldn't make Tomcat actually run better, so I favor changing things
> only if it brings something very tangible.
> Note: This time, I favor changing the API, as with TC 5, I think we got
> as far as we could without.
> Some of my first items would be:
> - refactor the request and response API using concrete classes
> (CoyoteRequest and CoyoteResponse) rather than interfaces, in order to
> simplify the code and lower the amount of RTTI and casts

+1 for doing this in the Catalina code.  Doing it in the Connector code
would mean that CoyoteConnector code for older TC versions would languish
off in a branch.

> - the current valve design mirrors the filters, but is actually
> different in what it can do (now that filters can work in request
> dispatchers), so I don't see the point of using the same pattern
> anymore; using the model from Tomcat pre-4.0 (yes, I know, it's old ;) )
> would lower the number method calls and reduce significantly the stack

I'm probably the number 2 fan of the Tomcat 3.3 API ;-), but it still has
its own set of drawbacks (e.g. it is very sensitive to editing server.xml).
Awhile back, Costin proposed using something along the lines of the Axis
Handlers (which are sort of a cross between the Catalina Valves and the TC 3
Interceptors).  Even if it isn't the Axis model, IMHO the ideal API would
combine both the strict chain of command of the Valves with flexability of
the Listener-like Interceptors.

> - more JMX, such as redoing the notification model (questionable, since
> the gain isn't too evident)
> - (definitely) flexible configuration persistence (instead of the hack
> that is currently used ;) )
> - I like the nested containers, and I think the server.xml structure is
> ok: I don't quite see how to simplify that without taking away from the
> functionality (Craig deserves some credit for the design, which aged
> rather well)
> - no non blocking IO for me, but introducing blocking NIO could be good
> This should keep me busy :)
> Rémy

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message