You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ru...@us.ibm.com on 2000/01/10 09:09:41 UTC
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next
Servlet Container
>So why not start fresh with Tomcat.next on a separate branch, reusing
>as much as possible from the existing code base? When you copy code to
>use in a new version like this, you tend to clean it up at the same time
>and add comments. I have the same feeling as Craig that this approach
>will take us to the goal a lot faster.
Speaking only for myself, I've invested considerable amount of time into
making sure that Jakarta works on Windows, JDK 1.1.X, and integrating in
patches which makes Jakarta work on Irix, EBCDIC machines, etc. I've also
seen considerable bug fixes and even a stray performance enhancement or two
get integrated - most of which are not architectural changes or even design
changes, but simple coding fixes. I don't see this work as being done, but
ongoing. None are these changes are significant in themselves, but the sum
total would be difficult to merge - inevitably resulting in lost changes
and more work.
Now I am contemplating servlet reloading. With the current architecture, I
would have likely made this code integral to Tomcat, but for performance
reasons would have made it optional. Now I'm contemplating making it
plugabble instead. However, if tomcat.next were on a separate branch, and
was not being implemented in a way that ensured that there was always a
working system to deal with, then I would most likely wait.
This is what concerns me most. Knowing that there is a separate branch
would have a chilling effect on all other development. Why fix a bug on
the current base when there is a new one only a few months away?
This is not simply one sided. By working on the same branch, there will be
more eyes reviewing the code, making fixes, or at least identifying issues.
For example, at the moment there is a regression in the watchdog servlet
tests that I have observed on both Win32/JDK1.1.8, and Linux/JDK1.2.
Whether it was directly tomcat.next changes or some subtle combinations of
changes, this regression was a surprise. One thing I do know is that such
issues are easier to track down knowing precisely when the regression was
introduced.
The only thing that would concern me more than the issues I described above
is if one or more people with significant value to contribute felt that
that cost of working together as a team was not worth it, and therefore
decided not to participate.
- Sam Ruby
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by Stefano Mazzocchi <st...@apache.org>.
rubys@us.ibm.com wrote:
>
> >So why not start fresh with Tomcat.next on a separate branch, reusing
> >as much as possible from the existing code base? When you copy code to
> >use in a new version like this, you tend to clean it up at the same time
> >and add comments. I have the same feeling as Craig that this approach
> >will take us to the goal a lot faster.
>
> Speaking only for myself, I've invested considerable amount of time into
> making sure that Jakarta works on Windows, JDK 1.1.X, and integrating in
> patches which makes Jakarta work on Irix, EBCDIC machines, etc. I've also
> seen considerable bug fixes and even a stray performance enhancement or two
> get integrated - most of which are not architectural changes or even design
> changes, but simple coding fixes. I don't see this work as being done, but
> ongoing. None are these changes are significant in themselves, but the sum
> total would be difficult to merge - inevitably resulting in lost changes
> and more work.
>
> Now I am contemplating servlet reloading. With the current architecture, I
> would have likely made this code integral to Tomcat, but for performance
> reasons would have made it optional. Now I'm contemplating making it
> plugabble instead. However, if tomcat.next were on a separate branch, and
> was not being implemented in a way that ensured that there was always a
> working system to deal with, then I would most likely wait.
>
> This is what concerns me most. Knowing that there is a separate branch
> would have a chilling effect on all other development. Why fix a bug on
> the current base when there is a new one only a few months away?
>
> This is not simply one sided. By working on the same branch, there will be
> more eyes reviewing the code, making fixes, or at least identifying issues.
> For example, at the moment there is a regression in the watchdog servlet
> tests that I have observed on both Win32/JDK1.1.8, and Linux/JDK1.2.
> Whether it was directly tomcat.next changes or some subtle combinations of
> changes, this regression was a surprise. One thing I do know is that such
> issues are easier to track down knowing precisely when the regression was
> introduced.
>
> The only thing that would concern me more than the issues I described above
> is if one or more people with significant value to contribute felt that
> that cost of working together as a team was not worth it, and therefore
> decided not to participate.
Very well said. I agree 100% with Sam on this.
Some of us like the incremental approach and some of us like the "branch
and merge" approach. Myself, I'm an old believer of the "branch and
merge" who understood that it simply doesn't work, or, if it does, it
requires much more work to be done, due to the fact that you are aiming
to a moving target.
But I totally understand how some of you guys feel: when people wiser
than me told the exact same words I didn't follow them. I was not able
to see the problem.
Now I am, but I can only show you the problems that _might_ come (with
Sam's words above).
Anyway, we are here to learn and open source dynamics are stronger than
any mistake we can make. True, it could create friction, slow down the
process and waste some double efforts, but learning is a painful and
expensive process.
So, again, I'm totally with Sam: I'd like the project to follow an
evolutionary path, but since I'm not the one that is going to work on
that code, who am I to decide?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by co...@costin.dnt.ro.
Patrick Regan wrote:
> Don't take this the wrong way, but I have found if you get into the habit of documenting
> your code as you are actually writing it, it's not that bad. We are all professionals
> here and know what the benefits are to documenting our code.
That's what I am doing, BTW.
In my understanding that documentation doesn't mean just putting "Add a context"
comments near addContext(), but making the code easy to read and getting rid
or documenting what is not so obvious - see the workDir handling, which I think
I "documented" by removing all the strange code that added and removed "/" and fixing
the 2 classes that depended on that.
I also have UML diagrams for core, and they look better and better ( IMHO, of course).
And I try to "take notes" - so we can have a "non-so-english" description of
how it works and of the current architecture.
Costin
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by Patrick Regan <pa...@globalcrossing.com>.
Don't take this the wrong way, but I have found if you get into the habit of documenting
your code as you are actually writing it, it's not that bad. We are all professionals
here and know what the benefits are to documenting our code.
Patrick Regan
costin@costin.dnt.ro wrote:
> > This is my greatest gripe with Tomcat.current: there's no documentation
> > so I can't tell if it's a good model or not without wading through massive
> > amounts of code. And the code has no comments, so I must actually analyze every
> > single line and build my own design models to see the big picture. I just don't
> > have the time to do that.
>
> First, if the design is not documented that doesn't mean it is bad.
>
> I want to write some documentation - but cleanup is more important right
> now and writing doc is much harder ( and time-consuming) than writing
> code. Computers understand easier !
>
> > > The design of Tomcat.current is not broken - and adding the new
> > > model of RequestInterceptors was very easy.
> >
> > It's easy for you; you have lived with this code for years.
>
> Less than 6 months.
>
> > > I don't mind seeing an implementation and comparing the 2, but switching tomcat
> > > to this model is very risky.
> >
> > So why not start the detailed design and implementation of Tomcat.next on
> > a separate branch? Then you can compare the models. But in order to have people
> > outside the original Tomcat development team compare the two, we need documentation
> > for Tomcat.current as well. Anyone volunteer to do that?
>
> I would ( and I will ), but after cleanup. Any help ( from English speakers :-) would
> be great.
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by co...@costin.dnt.ro.
> This is my greatest gripe with Tomcat.current: there's no documentation
> so I can't tell if it's a good model or not without wading through massive
> amounts of code. And the code has no comments, so I must actually analyze every
> single line and build my own design models to see the big picture. I just don't
> have the time to do that.
First, if the design is not documented that doesn't mean it is bad.
I want to write some documentation - but cleanup is more important right
now and writing doc is much harder ( and time-consuming) than writing
code. Computers understand easier !
> > The design of Tomcat.current is not broken - and adding the new
> > model of RequestInterceptors was very easy.
>
> It's easy for you; you have lived with this code for years.
Less than 6 months.
> > I don't mind seeing an implementation and comparing the 2, but switching tomcat
> > to this model is very risky.
>
> So why not start the detailed design and implementation of Tomcat.next on
> a separate branch? Then you can compare the models. But in order to have people
> outside the original Tomcat development team compare the two, we need documentation
> for Tomcat.current as well. Anyone volunteer to do that?
I would ( and I will ), but after cleanup. Any help ( from English speakers :-) would
be great.
Costin
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by Eduardo Pelegri-Llopart <Ed...@eng.sun.com>.
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
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 1/11/00 8:29 PM, Anil K. Vijendran at Anil.Vijendran@eng.sun.com wrote:
> 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,
Yep. I started a total rewrite of the JSDK for servlet 2.1 in about Nov or
Dec of 98. On a tangent, the name Tomcat came along then when I was sitting
in the dark of my office trying to decide a package name for the code that
would co-exist temporarily with the old code. So the code went into
com.sun.tomcat.* and the name stuck.
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet Container
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
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 +<:-)
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
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
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by ja...@almery.com.
Hans Bergsten writes:
> All comments about the design itself has been positive.
>
> I have reviewed it on a high level, and I feel it's a good model. It's hard
> to compare with the model used in Tomcat.current since it's not documented
> at all. This is my greatest gripe with Tomcat.current: there's no documentation
> so I can't tell if it's a good model or not without wading through massive
> amounts of code. And the code has no comments, so I must actually analyze every
> single line and build my own design models to see the big picture. I just don't
> have the time to do that.
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?
Thanks.
--
Jay Doane | doane@acm.org
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 1/10/00 12:56 PM, Hans Bergsten at hans@gefionsoftware.com wrote:
>> The design of Tomcat.current is not broken - and adding the new
>> model of RequestInterceptors was very easy.
>
> It's easy for you; you have lived with this code for years.
I have other comments that I'll address seperately -- but I wouldn't say
years on the code that's there. The code base that's there was restarted
from scratch a year ago. And it looks very different now than 6 months ago.
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
costin@costin.dnt.ro wrote:
>
> > Hopefully most of this would not be lost, because Tomcat.next will reuse
> > a lot of what's already in Tomcat.current. But yes, some of it may be lost.
> > On the other hand, there's a lot of inefficiencies in Tomcat.current that
> > has not been dealt with yet. The code has been around for a long time,
> > through a number of spec revs, and combined with time pressure this always
> > result in far from perfect solutions. If we start with Tomcat.next on a new
> > branch, I'm confident that the end result will be cleaner, more efficient,
> > and more efficient than if we try to force the new model onto Tomcat.current
> > in an evolutionary way. The evolutionary way most likely means adding new
> > adapter layers, unnatural temporary interfaces, etc.
>
> Yes, but besides implementation of Tomcat.next, it is also important to
> spend time in reviewing the design of Tomcat.next.
Yes, absolutely. I assume that's what Craig intended by sending out his proposal.
What surprises me is that there's been basically no discussions about the merits
of the design, only about if it should be done on a separate branch or not.
All comments about the design itself has been positive.
I have reviewed it on a high level, and I feel it's a good model. It's hard
to compare with the model used in Tomcat.current since it's not documented
at all. This is my greatest gripe with Tomcat.current: there's no documentation
so I can't tell if it's a good model or not without wading through massive
amounts of code. And the code has no comments, so I must actually analyze every
single line and build my own design models to see the big picture. I just don't
have the time to do that.
And I'm sure I'm not alone. That's why I said earlier that unless the original
designers, that know this design by heart, spend a lot of time documenting it,
it's pretty much impossible for anyone to help out with the cleanup. Sure,
minor bug fixes can be done without the "big picture" (as we have already seen),
but it's almost impossible to catch design problems and find more efficient
solution, or develop large new features.
I imagine that no one feels like writing this documentation now; it may even
be impossible since key people from the original development team has moved
on. That's why I feel starting from scratch, based on a documented, reviewed,
design is a better long term approach.
> Most of Tomcat.current problems are in implementation of various modules,
> in principal in parsing - and all that is already factored out in Interceptors.
> I don't thint the architecture of Tomcat.current is so broken - and it's just
> a matter of cleaning up.
>
> The design of Tomcat.current is not broken - and adding the new
> model of RequestInterceptors was very easy.
It's easy for you; you have lived with this code for years.
> On the other side, Tomcat.next interfaces are new and I don't think anyone
> but Craig reviewed them in detail. As I said, I see many problems in
> some of the concepts used - initialization via Lifecycle that requires
> DOM and is only at startup ( no reconfiguration, no setter/getter for
> configurable properties - from this point of view the current tomcat
> is much better - IMHO !).
>
> The "hierarchy of containers" concept which is hevily used is very
> new and original - I know no other server that uses it, and I see many problems
> with it. IMHO, the model used by Apache is far better - and is
> the model used in tomcat.current ( set of Interceptors that process request).
I agree it needs to be reviewed in detail. Why don't we?
> I don't mind seeing an implementation and comparing the 2, but switching tomcat
> to this model is very risky.
So why not start the detailed design and implementation of Tomcat.next on
a separate branch? Then you can compare the models. But in order to have people
outside the original Tomcat development team compare the two, we need documentation
for Tomcat.current as well. Anyone volunteer to do that?
> So please add to the 1-2 months of implementation some time to
> think about the _details_ of tomcat.next. It is after all a set of interfaces
> that set a lot of contracts - and I don't think we can agree that we should
> start implementing a specification without even a minimal review.
Again, I agree about the review. Craig's proposal is there; let's tear it
apart and put it back again into something we all agree on. But I don't see
why we should stop Craig and others from starting to implement it and refine the
design docs as we go.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by co...@costin.dnt.ro.
> Hopefully most of this would not be lost, because Tomcat.next will reuse
> a lot of what's already in Tomcat.current. But yes, some of it may be lost.
> On the other hand, there's a lot of inefficiencies in Tomcat.current that
> has not been dealt with yet. The code has been around for a long time,
> through a number of spec revs, and combined with time pressure this always
> result in far from perfect solutions. If we start with Tomcat.next on a new
> branch, I'm confident that the end result will be cleaner, more efficient,
> and more efficient than if we try to force the new model onto Tomcat.current
> in an evolutionary way. The evolutionary way most likely means adding new
> adapter layers, unnatural temporary interfaces, etc.
Yes, but besides implementation of Tomcat.next, it is also important to
spend time in reviewing the design of Tomcat.next.
Most of Tomcat.current problems are in implementation of various modules,
in principal in parsing - and all that is already factored out in Interceptors.
I don't thint the architecture of Tomcat.current is so broken - and it's just
a matter of cleaning up.
The design of Tomcat.current is not broken - and adding the new
model of RequestInterceptors was very easy.
On the other side, Tomcat.next interfaces are new and I don't think anyone
but Craig reviewed them in detail. As I said, I see many problems in
some of the concepts used - initialization via Lifecycle that requires
DOM and is only at startup ( no reconfiguration, no setter/getter for
configurable properties - from this point of view the current tomcat
is much better - IMHO !).
The "hierarchy of containers" concept which is hevily used is very
new and original - I know no other server that uses it, and I see many problems
with it. IMHO, the model used by Apache is far better - and is
the model used in tomcat.current ( set of Interceptors that process request). I don't
mind seeing an implementation and comparing the 2, but switching tomcat
to this model is very risky.
So please add to the 1-2 months of implementation some time to
think about the _details_ of tomcat.next. It is after all a set of interfaces
that set a lot of contracts - and I don't think we can agree that we should
start implementing a specification without even a minimal review.
Costin
Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.NextServlet
Container
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
rubys@us.ibm.com wrote:
>
> >So why not start fresh with Tomcat.next on a separate branch, reusing
> >as much as possible from the existing code base? When you copy code to
> >use in a new version like this, you tend to clean it up at the same time
> >and add comments. I have the same feeling as Craig that this approach
> >will take us to the goal a lot faster.
>
> Speaking only for myself, I've invested considerable amount of time into
> making sure that Jakarta works on Windows, JDK 1.1.X, and integrating in
> patches which makes Jakarta work on Irix, EBCDIC machines, etc. I've also
> seen considerable bug fixes and even a stray performance enhancement or two
> get integrated - most of which are not architectural changes or even design
> changes, but simple coding fixes. I don't see this work as being done, but
> ongoing. None are these changes are significant in themselves, but the sum
> total would be difficult to merge - inevitably resulting in lost changes
> and more work.
Hopefully most of this would not be lost, because Tomcat.next will reuse
a lot of what's already in Tomcat.current. But yes, some of it may be lost.
On the other hand, there's a lot of inefficiencies in Tomcat.current that
has not been dealt with yet. The code has been around for a long time,
through a number of spec revs, and combined with time pressure this always
result in far from perfect solutions. If we start with Tomcat.next on a new
branch, I'm confident that the end result will be cleaner, more efficient,
and more efficient than if we try to force the new model onto Tomcat.current
in an evolutionary way. The evolutionary way most likely means adding new
adapter layers, unnatural temporary interfaces, etc.
> Now I am contemplating servlet reloading. With the current architecture, I
> would have likely made this code integral to Tomcat, but for performance
> reasons would have made it optional. Now I'm contemplating making it
> plugabble instead. However, if tomcat.next were on a separate branch, and
> was not being implemented in a way that ensured that there was always a
> working system to deal with, then I would most likely wait.
>
> This is what concerns me most. Knowing that there is a separate branch
> would have a chilling effect on all other development. Why fix a bug on
> the current base when there is a new one only a few months away?
Yes, that is the biggest risk. But since Tomcat.next will, most likely, not
be usable until it's almost done, anyone who needs a bug fixed "today" will
have to do it on the main branch no matter what. So I'm not too concerned
about bug fixes not being done on the current branch, but there's a risk that
new features are not being added on the main branch while we wait for Tomcat.next.
But Craig's estimate is 1 - 2 months for completion of Tomcat.next. I'm willing
to wait for some of the new major features. Small features, like URL rewriting,
will likely be done on the main branch anyway, since they are similar to bug
fixes (actually, URL rewriting *is* a bug fix; it's mandatory according to the
Servlet 2.2 spec).
> This is not simply one sided. By working on the same branch, there will be
> more eyes reviewing the code, making fixes, or at least identifying issues.
> For example, at the moment there is a regression in the watchdog servlet
> tests that I have observed on both Win32/JDK1.1.8, and Linux/JDK1.2.
> Whether it was directly tomcat.next changes or some subtle combinations of
> changes, this regression was a surprise. One thing I do know is that such
> issues are easier to track down knowing precisely when the regression was
> introduced.
This is my biggest concern with the evolutionary model; by forcing a new
model on the old code, the risk for regression is very high. That's always the
case when you do major architectural changes in existing code. An additional
problem here is that without comments, it's a fairly small number of people
that actually understand why the code looks the way it does.
Writing a new servlet container from scratch is not a huge amount of work.
I've done it myself in a little bit more than a week, and that server is used
by hundreds of people all over the world with just a handful of bugs reported in
the year it's been in use. With people like you, Craig, and all the other active
committers, in this project, I don't see any problems at all getting a high
quality and flexible container developed in 1 - 2 months.
> The only thing that would concern me more than the issues I described above
> is if one or more people with significant value to contribute felt that
> that cost of working together as a team was not worth it, and therefore
> decided not to participate.
That's pretty much what I read between the lines. And since the cleanup of
Tomcat.current, with the goals stated in the 3.1 release plan, done in parallel
with the development of Tomcat.next on a new branch will likely resolve this
issue, I say why not?
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com