tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Jasper Changes
Date Fri, 22 Sep 2000 00:52:12 GMT
Alex Chaffee wrote:

> On Thu, Sep 21, 2000 at 03:42:31PM -0700, Craig R. McClanahan wrote:
> > Alex Chaffee wrote:
> >
> > > OK, everyone likes the spin-off idea in theory.  Now, before I open up
> > > Craig's gotchas, let me ask:
> > >
> > > Should it live in
> > >
> > > 1) jakarta-tomcat/jasper
> > > 2) jakarta-tomcat-4.0/jasper
> > > 3) jakarta-jasper/
> > >
> > > I vote for 3.  How hard is it to set up a new repository?
> > >
> >
> > Does 3 accomplish something fundamentally important that 2 doesn't, or is this just
> > for show?  :-)
> Yes, it reinforces the fact that Jasper is a separate product from
> either version of Tomcat,

By itself, this action would perpetuate a justifiable confusion among users of Tomcat,
who ask "what in the heck is it?"

Well, our web site says what Tomcat has always meant (and I see know reason to change it,
other than updating the version numbers):  a world-class implementation of the Java
Servlet 2.2 and JavaServer Pages 1.1 Specifications.  In other words, "Tomcat = Servlets
+ JSP".

For instance, you can ship a servlet container based on the Tomcat 4.0 servlet container
code (Catalina) without the JSP engine, and add anything else you want -- but it's not
Tomcat any more at that point.

Likewise, you can take Jasper and plug it in to a different servlet container and ship it
-- the Apache license is wonderful that way -- but again, it's not Tomcat.

How that is relevant in this discussion is that if you split the JSP engine out as a
separate project, you need to do the same with the servlet container, which needs its own
unique name as well -- in either a 3.x or 4.0 environment -- to avoid confusion.  For the
4.0 world that name already exists (even in the bugs database :-) -- in 3.x the name
"Tomcat" is pretty ambiguous.

> and diminishes the temptation to submit bug
> fixes and (non-spec-oriented) feature additions to one or the other
> source tree (excluding the other and leading to source fragmentation).

On the servlet container side, the code bases are so totally separate already that there
isn't any reasonable mechanism to share anything more than basic utility classes -- and I
got tired of doing that when people kept making changes to meet 3.x needs (a perfectly
legitimate thing to do) without considering the fact that it would break the 4.x code.

The JSP side needs a similar overhaul.  Once you make fundamental changes in the internal
organization, implementing any substantial new feature is two development efforts, not
one, no matter how you slice it.

> ---
> As for the rest of your message -- I may have time to reply in more
> detail later but --
> Given that JSP 1.1 files should run flawlessly in a JSP 1.2 container,
> the only obstacle I see to merging the two is the classfile
> dependencies on the Servlet 2.3 container.
> If these cannot be resolved programmatically (and I have a sinking
> feeling they can't), then I propose a version-numbering sort of code
> freeze:

Good luck trying to fix this programmatically (it is not just the engine -- the JSP code
generator would have to create version-specific Java code for the servlets it creates,
plus you'd need two versions of most of the runtime support infrastructure).

IMHO it's not worth the effort.

> Jasper 1.0 is declared to be the version that shipped with Tomcat 3.x,
> and supports JSP 1.1 and can be deployed on a Servlet 2.2 container
> Jasper 2.0 is declared to be the current code base, supporting JSP 1.2
> and requiring Servlets 2.3
> Each version will have a build option, selectable at
> build.bat/ time
> Until and unless Tomcat 3.x supports a 2.3 facade, it will continue to
> ship with Jasper 1.0 (the included jasper.jar will be version 1.0)
> At the time Tomcat 3.x gets a facade, it will switch to shipping with
> Jasper 2.0 (the included jasper.jar will be version 2.0)
> Unfortunately, this still leads to fragmentation :-(

It's an unavoidable price of progress, especially on major version changes.  Labelling
things, or rearranging CVS directories, isn't going to change a thing in that regard.

>  - A
> --
> Alex Chaffee             
> jGuru - Java News and FAQs
> Creator of Gamelan       
> Founder of Purple Technology
> Curator of Stinky Art Collective
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

See you at ApacheCon Europe <>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat

View raw message