You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Eduardo Pelegri-Llopart <Ed...@eng.sun.com> on 2000/01/12 19:13:40 UTC

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet Container

and, since we are into history, on the JSP spec side there had been a
number of different specs available in 1998.  When Satish left for fame,
glory, and $$s, Larry and I took over the JSP spec effort.  There was
some process reset, rethinking, and changes to the spec and we were
pretty much in catch-up mode through most of 1999.  Kudos to the
implementation team for tracking the spec as well as they did, and
thanks much to everybody who helped with the spec in getting it in
shape.  A consequence of this wild ride is that the implemntation had to
twist and turn more often than ideal, which probably leaked into the
code structure.

	- eduard/o

"Anil K. Vijendran" wrote:
> 
> Thanks for the nice history, Craig. I thought I'd add a couple of
> paragraphs on Tomcat's history too.
> 
> On the Tomcat side of things, this code was derived from what used to be
> called first JSDK (Java Servlet Development Kit) for Servlet 2.1 API, then
> became JSWDK (JavaServer Web Development Kit) 1.0 with Servlet 2.1 and JSP
> 1.0 and went through three releases, LOTS of bugfixes and other
> enhancements.
> 
> Then the JSWDK codebase got "revved" to Servlet 2.2 and JSP 1.1 and got
> into the J2EE server. If I remember right, even the package names of JSWDK
> servlet engine classes were all com.sun.tomcat :-) (and com.sun.jsp)
> 
> The Tomcat codebase is not that old really. If memory serves me
> right, James Duncan Davidson wrote an initial servlet engine in late 98
> and I wrote the JSP engine in early 99.
> 
> Much of the "cruft" that is visible now came during the J2EE code slush
> when we had to implement all of Servlet 2.2 and JSP 1.1 and integrate it
> into the J2EE server in a very short time.
> 
> On Tue, 11 Jan 2000, Craig R. McClanahan wrote:
> 
> > ja@almery.com wrote:
> >
> > > Sorry if this is a little offtopic.  And please don't take offense;
> > > this question is not meant as flamebait!
> > >
> > > I'm curious if someone can point me to a discussion or perhaps explain
> > > the reasoning behind effectively abandoning the JServ codebase and
> > > adopting Tomcat's codebase as the standard java-apache servlet engine.
> > >
> > > I wasn't around for JServ, so I don't know anything about the merits
> > > of its design and documentation, but there must have seemed to be a
> > > compelling reason (or reasons) to give it up (as opposed to, say,
> > > refactoring).
> > >
> > > Could someone summarize?
> > >
> >
> > You'll probably get as many different answers as there were people involved.  The
> > following is my personal viewpoint and opinions -- I don't think there is any such
> > thing as an "official" position of the Apache JServ development group.
> >
> > For background, I joined the Apache JServ project in January, 1999.  The personal
> > itch I wanted to scratch (with apologies to ESR) was to bring Apache JServ up to
> > compliance with the 2.1 servlet API, which was still current at the time.  As you
> > probably remember, Apache JServ is based on the 2.0 API, and there were some really
> > significant changes between 2.0 and 2.1.
> >
> > After working with the existing code for a while, it became obvious that some
> > fundamental design decisions were going to need to change to support 2.1.  In
> > addition, many of the then-current developers of Apache JServ started getting
> > interested in other things (Jon -> ECS, Village, Town, and Turbine; Pier -> XML;
> > Stefano -> Cocoon).  I therefore took advantage of the opportunity to propose a
> > rearchitecting of Apache JServ to both bring it up to date, and provide a basis for
> > future flexibility.  The idea was accepted, and work proceeded -- not a lot different
> > than the Tomcat.Next proposal being discussed here.
> >
> > The code that was created for this is actually funtional, although it has not been
> > stress tested or performance tuned.  It is still in the Apache JServ CVS tree, under
> > branch "JSERV1_1DEV" (originally it was going to be called 1.1).
> >
> > Now, fast forward to June, 1999, and the announcement at JavaOne.  Sun was doing what
> > open source advocates had been suggesting for quite a while -- they were contributing
> > the source code of the JSWDK to the Apache Software Foundation!  And they would
> > continue to support the project, including some developers paid to contribute
> > enhancements.  Further, Tomcat would remain the reference implementation for the
> > servlet and JSP APIs.
> >
> > Now, if you're in the shoes of developers, which servlet engine are you going to keep
> > -- one developed over time by a few volunteers at any given time, and that was
> > already a year out of date, or one that already implemented the new servlet 2.2 and
> > JSP 1.1 standards (at least to the draft state they were then), and was essentially
> > guaranteed to be kept up to date because it would be the reference implementation?
> > That's pretty much a no-brainer.
> >
> > The day that Jakarta was announced, interest in JSERV1_1DEV (including from me)
> > basically died.  Why bother to work on it, when it was going to get replaced?  Had
> > Jakarta not happened, you would have seen an Apache JServ release based on the new
> > code sometime last year.  Once Jakarta came along, there was essentially no interest
> > in doing so.
> >
> > Next, "slow forward" to October, and the code is finally released.  (I don't know all
> > the details, but I do know that anyone who blames all of that delay on Sun and Sun's
> > lawyers hasn't got a clue.)  The Tomcat code had never been designed to be
> > functionally compatible with Apache JServ, or even Apache -- making that connection
> > was one of the very first work tasks, and is present in the Tomcat 3.0 release.
> > Tomcat had never had to compete on functionality, so it was missing a bunch of stuff
> > (although I must confess to surprise at some of the things, like URL rewriting, that
> > had been omitted).
> >
> > Work is in progress to resolve those differences and add the missing features.  And,
> > we've come full circle :-) -- is it best to continue on the existing code base, or
> > use what we've learned and rebuild it.  I guess we all need to stay tuned for the
> > rest of that story ...
> >
> > >
> > > Thanks.
> > >
> > > --
> > > Jay Doane | doane@acm.org
> > >
> >
> > Craig McClanahan
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> 
> --
> Peace, Anil +<:-)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org