tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee <>
Subject Re: Jasper Changes
Date Thu, 21 Sep 2000 21:12:46 GMT
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?  

Changing the build scripts for tomcat/catalina is not hard -- I like
Ant -- we just <copydir src="../jakarta-jasper/src" dest="{}"/> 
or some such.

> In the migration to the "jakarta-tomcat-4.0" workspace, this has already been
> functionally and technically separated (although it wasn't really advertised
> all that much).
> The "jakarta-tomcat-4.0" workspace has the following top level
> subdirectories:
>     catalina -- The 2.3-compatible servlet container
>     jasper -- The 1.2-compatible JSP container
>     webapps -- The 2.3/1.2 compatible example applications
> Each of these three top level subdirectories contains completely independent
> build scripts, so you can build what you want and use it separately.  So, for
> example, you can build a servlet container with no JSP engine by just going
> into the catalina directory and doing a "build dist".  Likewise, the "jasper"
> directory's "build dist" will create a JSP engine you can take anywhere that
> is 2.3/1.2 compatible.

Unfortunately, there's also
which contains different code than
and now needs to be merged. :-(

> > Remember, we want Jasper to work with any servlet engine, including
> > Tomcat 3, and including other Servlet 2.2 containers.
> >
> There are two gotchas to this portability goal:
> * The new Jasper code requires Servlet 2.3 and JSP 1.2 support, so it

(By the way, your phrase "and JSP 1.2" is a mistake, right?  It
*implements* JSP 1.1 or 1.2, so how can it "require" JSP 1.2?)

>   won't run on 2.2 containers.

I'm not familiar enough with Jasper to know how best to solve this.  I
can imagine at least three possibilities (potentially overlapping):

* a single code base, where 2.3-specific method calls are wrapped in
"catch (NoSuchMethodError)" and fall back to either 2.2-specific
implementations, or throw an exception (where the functionality is
impossible to provide)

(or, instead of catching an exception, it could switch on the results
of context.getMajorVersion()/getMinorVersion() -- taking the context
at its word what version it supports)

* a set of separate peer classes for JSP 1.1 and 1.2 that are
instantiated on the fly based on which version mode it's running in

* a separate build process for Jasper-supporting-JSP-1.1 and

It's a tough one.  I'm leaning towards the first but it may be
difficult to do across all Jasper code.

Let me ask another question:

Is there any reason for a JSP-1.1-only version of Jasper to exist?  Or
should we transparently allow (force?) everyone using Jasper to use
JSP-1.2 features?

In other words, are there any backwards-incompatible features of the
JSP-1.2 spec?  Or will any JSP-1.1 compliant .jsp file run identically
in a JSP-1.2-compliant JSP container?

> * Although there are zero code dependencies between Jasper and Catalina,
>   there is a dependency on setting a servlet context attribute correctly to
>   pass the webapp classpath to the Jasper servlet.  This same dependency
>   (plus some code dependencies) is currently present in Tomcat 3.x.
> However, Jasper should run fine on any 2.3 container that is hacked to set
> the right context attributes.  And Jon is free to package Catalina (without
> Jasper) with any page template language he wants :-).

I'm not quite sure I understand this completely but it sounds solved. :-)

 - A

Alex Chaffee             
jGuru - Java News and FAQs
Creator of Gamelan       
Founder of Purple Technology
Curator of Stinky Art Collective

View raw message