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 Thu, 21 Sep 2000 22:42:31 GMT
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?  :-)

> 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
> jakarta-tomcat/src/share/org/apache/jasper/*
> which contains different code than
> jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/*
> and now needs to be merged. :-(

Note that the "jakarta-tomcat/src/share/org/apache/jasper" code was the basis for
the Jasper code in "jakarta-tomcat-4.0".  It's in the process of being
substantially remodelled (based on the proposal that was presented and voted on
last month), partly due to the new spec requirements (including the requirement to
accept pages in XML format and expose them as an XML stream to validator classes in
custom tag libraries), partly to improve the portability (remove dependencies on
org.apache.tomcat code, which is already done), and partly to provide a clean basis
for improving the quality of the generated code.

Therefore, I disagree (with the idea that it needs to be merged) -- but see more

> > > 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?)

It *requires* the servlet 2.3 and JSP 1.2 version of "servlet.jar".  Jasper
*implements* the JSP 1.2 part of the API, in the same way that Catalina
*implements* the Servlet 2.3 part.

> >   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)

Ask Costin (and others) how easy it has been to support JDK 1.1 and JDK 1.2 in the
same container :-).  It is really hard to do this right, without substantial
impacts on your performance (i.e. having to use reflection) or code maintenance
(two versions).

> * 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
> Jasper-supporting-JSP-1.2
> 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?

The only way to get JSP 1.2 is run on a servlet 2.3 container (i.e. the specs are

For example, JSP 1.2 lets you say <jsp:include page="..." include="false/>, but
implementing this requires the new 2.3 feature of being able to wrap the arguments
to a RequestDispatcher.include() call.  This is not going to work on a 2.2
container that depends on the current (2.2) restriction that the arguments must be
the original request and response objects.

> 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?

As things stand right now (and as is currently true of Tomcat 4.0 for everything
I've tested so far), 100% of servlet 2.2 / JSP 1.1 applications should run under
containers implementing the new specs, unless they depend on bugs in the
implementation of their existing container.  Failure to do this is a bug.

There are a very small number of clarifications likely to be included in the final
2.3 release covering some issues that are not currently specified, and where
experience has shown that containers vary in their implementation (example:  is a
relative argument to response.sendRedirect() interpreted as context-relative or
server-relative?).  If the final answer to this one differs from what Tomcat 3.x
currently does (which interprets it as server-relative), there will be a
compatibility issue due to the spec requirement.  But other than that kind of
thing, every app that runs under Tomcat 3.x should work fine under Tomcat 4.0 as

Which, going back to the earlier point, raises the question that we are all
tiptoeing around:  what is the future of the Tomcat 3.x code base after 3.2 goes
final?  While bug fix support (and perhaps 3.2.1 or 3.2.2 releases) might be needed
before Tomcat 4.0 is production quality (it undoubtedly has bugs that need to be
shaken out, but nearly all of the bug reports recently on 3.1 and 3.2 are for
things that already work correctly in 4.0 :-), I have no personal time or energy or
interest in continuing down the current path (although there's a bunch of good
ideas on performance tuning that can be harvested).

Others, of course, will have different opinions.  It's open source -- people can do
what they want.

As for me, I'm putting my time/talent/energy into making a 4.0 release that fully
implements the new specs, has quite a few interesting new features outside of
spec-related things, and is of at least beta quality by ApacheCon Europe (October
23-25).  Look for milestone releases between now and then to supplement the nightly
builds that are already available.

> > * 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. :-)

It means that no reorganization of the current source code base is required to
accomplish the goal of separating the JSP engine from the core servlet container

> Alex Chaffee             


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