tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Sun, 09 Jan 2000 23:53:39 GMT
"Craig R. McClanahan" wrote:
> Hans Bergsten wrote:
> > [snip]
> >
> > Revolution vs. evolution
> > ------------------------
> > It seems like this discussions came to the conclusion that we should do
> > both; move towards when we clean up the code, and possibly
> > start from scratch with a "refactoring" effort in a separate CVS directory (not
> > a branch). I can live with this approach, especially since I see pros and
> > cons with both approaches and can't say which one is the "right" one ;-)
> >
> I wish that were the conclusion that was reached; however, parallel processing (via a
> branch for Tomcat.Next) got -1'd.  I very much favor the two-track approach -- bug
> fixes and enhancements on the existing code base as needed, and a CVS branch (starting
> with just the component interfaces plus a bunch of discussion to agree on the method
> signatures in those interfaces).

Okay, maybe I read more into some parts of the discussion than was there ...
But it seems like a reasonable approach to me.

> > Questions
> > ---------
> > A couple of questions that I have not seen any discussion about yet are:
> >
> > * Why are Request/Response representations of HttpServletRequest/Response
> >   instead of ServletRequest/Response?
> >
> It's based on my feeling that Tomcat is, first and foremost, an *HTTP* servlet
> container.  Most of the design energy and features focus is around things that only
> matter when the container knows the contents of the HTTP headers.
> It would be reasonable to build a servlet engine for non-interactive, non-HTTP-based
> request/response stuff, but I don't see a lot of value add for doing this versus
> alternative solutions based on RMI and/or CORBA APIs.

I was thinking about things like WebDAV, and possibly WAP. I imagine a server
for these protocols may need other ServletRequest/Response subclasses than

> > * What's the motivation for calling Interceptor preService() in LIFO order
> >   and postService() in FIFO order? To me it would be natural to use LIFO
> >   for both, but I'm sure I'm missing something here.
> >
> The idea is that a particular interceptor is a layer -- it wants to be as independent
> as possible of the layers above it and below it.  So, for a particular interceptor, I
> want to have my preService() method called on the way in before any lower Interceptor
> is invoked, and I want my postService() method called after any lower Interceptor has
> finished. [...]

Great, I got it. Could you add this description to the proposal? I know you said
you would not touch the proposal anymore, but I believe this will help others
as well to understand the proposal better.

> > So, thanks Craig for a great proposal. I hope we can get there soon.
> Given that the functional code already exists and just needs to be reorganized some,
> this is about 1-2 months effort if you do it on a separate branch, but more like 4-5
> months if you do it incrementally on the main branch, with the requirement that it
> always has to work at any given moment.

I hear you ;-) Can we restart the discussion about running it in parallel on a
separate branch?

Hans Bergsten
Gefion Software

View raw message