You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by pi...@locus.apache.org on 2000/08/30 22:09:36 UTC
cvs commit: jakarta-tomcat-4.0/jasper/doc/dev Architecture.html README.html TODO.html jasper-independent.html jasper-proposal.html status.html
pierred 00/08/30 13:09:35
Added: jasper/doc jspc.html
jasper/doc/dev Architecture.html README.html TODO.html
jasper-independent.html jasper-proposal.html
status.html
Log:
A set of "developer" docs that hopefully will help set the stage
to get us going with this next release of jasper.
Point your browser to jakarta-tomcat-4.0/jasper/doc/dev/README.html
to get the story... and please provide feedback if you have any interest
in jasper development.
Revision Changes Path
1.1 jakarta-tomcat-4.0/jasper/doc/jspc.html
Index: jspc.html
===================================================================
<html>
<head>
<title><jspc></title>
</head>
<body>
<h1>jspc</h1>
<pre>
Usage: jspc <options> [--] <jsp files>
where jsp files is any number of:
<file> A file to be parsed as a jsp page
-webapp <dir> A directory containing a web-app, all jsp pages
will recursivly be parsed
where options include:
-q Quite mode (same as -v0)
-v[#] Verbose mode (optional number is level, default is 2)
-d <dir> Output Directory
-dd <dir> Literal Output Directory. (package dirs will not be made)
-p <name> Name of target package
-c <name> Name of target class name
(only applies to first JSP page)
-mapped Generate separate write() calls for each HTML line in the JSP
-die[#] Generate an error return code (#) on fatal errors.
If the number is absent or unparsable it defaults to 1.
-uribase <dir> The uri directory compilations shoule be relative to
(Default is "/")
-uriroot <dir> The root directory that uri files should be resolved
against, (Default is the directory jspc is invoked from)
-webinc <file> Creates partial servlet mapings for the -webapp option
-webxml <file> Creates a complete web.xml when using the -webapp option.
-ieplugin <clsid> Java Plugin classid for Internet Explorer
</pre>
<p>
<i>Yes, we could do better... new doc coming up soon!!!</i>
</body>
</html>
1.1 jakarta-tomcat-4.0/jasper/doc/dev/Architecture.html
Index: Architecture.html
===================================================================
<h1>Jasper Architecture</h1>
Coming up soon...
1.1 jakarta-tomcat-4.0/jasper/doc/dev/README.html
Index: README.html
===================================================================
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Pierre Delisle">
<meta name="GENERATOR" content="Mozilla/4.73 [en] (WinNT; U) [Netscape]">
<title>Jasper -- README</title>
</head>
<body>
<h2>
What is Jasper?</h2>
Jasper is the reference implementation of the
<a href="http://java.sun.com/products/jsp">JSP
specification</a>. It is packaged in Tomcat along with Catalina (the reference
implementation of the <a href="http://java.sun.com/products/servlet">Servlet specification</a>). <p>
It is a goal to have Jasper as a component that is independent of Catalina (and vice-versa). We're currently working on this.
<h2>Status</h2>
The Jasper code base is going through a substantial reorganization
following the evolution of tomcat-3.x to tomcat-4.0. Tomcat-4.0 is the first release to support the new
Servlet 2.3 and JSP 1.2 specifications.
<p>
<ul>
<li><a href="jasper-proposal.html">Proposal for Development of Jasper in Tomcat 4.0</a>
<br>
The document defines the set of goals as well as a high level architecture for this new version of Jasper.<br>
<li><a href="status.html">Status</a>
<br>
This document gives up to date (well... we'll try!)
information on the current status of Jasper.
<li><a href="TODO.html">Todo</a><br>
This is a compilation of the work we are hoping to get done on Jasper.
</ul>
<h2>Documentation</h2>
<ul>
<li><a href="Architecture.html">Architecture</a>
<br>
Overall description of Jasper architecture. Come here first to understand how the code base is architected and how the whole thing works.
<li><a href="../../../../build/jasper/javadoc/index.html"</a>Javadocs</a>
<br>
You can get the javadocs of the Jasper APIs simply by running the command "build javadoc" in the jasper directory, and pointing your browser to file:<tomcat-dir>/build/jasper/javadoc
<li>
<a href="../jspc.html">jspc</a><br>
User documentation for the jasper command line tool.
1.1 jakarta-tomcat-4.0/jasper/doc/dev/TODO.html
Index: TODO.html
===================================================================
<html>
<head>
<title>Jasper -- TODO</title>
<body>
<h1>Jasper TODO list</h1>
<ul>
<li><a href="#jsp12">JSP 1.2 Compliance</a></li>
<li><a href="#independentcomp">Jasper as an independent component</a></li>
<li><a href="#bugs">Bugs</a></li>
<li><a href="#rfes">RFEs</a></li>
</ul>
<hr>
<a name="jsp12"><h2>JSP 1.2 Compliance</h2></a>
A new version of the JavaServer Pages specification <a
href="http://java.sun.com/products/jsp">(JSP 1.2)</a> has entered
public draft status on 2000/08/15. As part of the effort to validate the
changes and new features, we need to enhance the existing Jasper
implementation to support them in the very near term. This section
describes each of the major new features (as presented in section B.1 of
the Public Draft 1), and summarizes the likely code changes required to
implement them.
<h3>jsp:include can now indicate "flush='false'"</h3>
The JSP 1.1 specification requires that the "flush" attribute of a
<jsp:include> tag always be set to "true". In 1.2, a "false" value is allowed, with the following semantics:
<ul>
<li>
The content will be included in the current JspWriter instead of being
sent to the top-level writer (and hence to the output stream).
<li>The included page cannot set headers or cookies.
</ul>
Implementation of this change affects the Java code generated by the JSP
page compiler, and relies on the new RequestDispatcher semantics of the
Servlet 2.3 spec. Basically, the generated code will need to create
a wrapped response, to be passed as the second argument to the internal
RequestDispatcher.include() that implements this element, which grabs all
the output text and copies it to the current JspWriter.
<h3>Made the XML view of a JSP page available for input, and for validation</h3>
This is one of the main issues that has motivated the need
to re-architect Jasper into phases, and to provide an additional parser that
accepts input in the XML syntax.
<p>
Two parsers now need to coexist in our implementation, and our "generators" will also need to support the production of an input stream in XML syntax which is then passed to the new Validator class for validation against tag libraries.
<h3>PropertyEditor.setAsText() can now be used to convert from a literal string attribute value</h3>
From the spec:
<quote>
String constants and request parameter values can be used to assign values to any a type that has a PropertyEditor class. When that is the case, the setAsText(String) method is used.
<h3>New ValidatorClass and JspPage classes for validation against tag libraries</h3>
This is the infrastructure added in the tag libraries to support the validation
phase introduced with the support of the XML syntax (see "Made the XML view of a JSP page available for input, and for validation" above).
<h3>New IteratorTag interface to support iteration without BodyContent</h3>
In JSP 1.1, your custom tag must implement BodyTag if it wants to support
iteration. In many simple cases where the nested content of a tag is just
reprocessed by the iteration anyway, it would be nice to allow a custom tag
class that only implements Tag to be able to iterate, with the convenience
base class doing the iteration without creating a nested BodyContent. This
should also have performance benefits for this use case.
This should require fairly minor changes to the generated
code for a page using custom tags. Updated support classes will already be
part of the API.
<h3>Added listener classes to the TLD</h3>
With the advent of application events support in Servlet 2.3, it is
now possible for tag libraries to define an event listener object.
Changes related to this addition are taken care of by the servlet container:
<ul>
<li> When processing the web application deployment descriptor at
application start time, take specific note of each included <taglib>
directive.
<li> For each <taglib> directive, find and parse the corresponding tag
library descriptor, and register application event listeners in the
same manner that listeners in web.xml are registered.
</ul>
@@@ Craig -- is the above still right? what about the comment below? @@@
It is also possible that a particular TLD will be encountered for the first
time when a page is compiled at runtime. Final resolution of what to do in
this case has not yet been decided.
<h3>Added elements to the TLD to avoid having to write TagExtraInfo classes in the most common cases</h3>
The container needs to hanlde appropriately the new optional scripting variable information specified via new <variable> tag (sub element of <tag>).
<h3>Added a resetCustomAttributes() method to Tag interface</h3>
This new method allows the reuse of tag instances in cases where the invocations of the tag do not set the same attributes. We should revisit our tag lifecycle implementation and improve accordingly.
<h3>Added elements to the TLD for delivering icons and descriptions to
use in authoring tools</h3>
Nothing to be done here.
<hr>
<a name=independentcomp><h2>Jasper as an independent component</h2></a>
[From <a href="jasper-proposal.html">Proposal for Development of Jasper in Tomcat 4.0</a>]
<p>
It shall be possible to embed the JSP page compiler as a servlet in any servlet container conforming to the Servlet
2.3 Specification (not just Tomcat). Among other things, this implies that there shall be no internal code
dependencies within Jasper on any classes in the org.apache.tomcat.* package hierarchy. <a href="jasper-independent.html"/>Progress Document</a>.
<p>
<hr>
<a name=bugs><h2>Bugs</h2></a>
Tomcat bugs are currently tracked at <a href="http://znutar.cortexity.com:8888/BugRatViewer">http://znutar.cortexity.com:8888/BugRatViewer</a>. Jasper has its own project name, so you can easily get a report showing only jasper related bugs.
<hr>
<a name=rfes><h2>RFEs</h2></a>
</body>
</html>
1.1 jakarta-tomcat-4.0/jasper/doc/dev/jasper-independent.html
Index: jasper-independent.html
===================================================================
<html>
<head>
<title>Jasper as an independent component</title>
</head>
<body>
<h1>Jasper as an independent component</h1>
<h3>Migration from tomcat-3.x to tomcat-4.0</h3>
In tomcat3.x, jasper had the following package dependencies with the servlet container code:
<ul>
<li><code>tomcat.util</code>
<li><code>tomcat.logging</code>
<li><code>tomcat.core</code>
</ul>
These three directories were copied into jasper. Cleanup has been made in util to only keep the files needed by Jasper. The following dependencies are still remaining:
<p>
<pre>
org.apache.jasper.Constants:
public static final String SERVLET_CLASSPATH = "org.apache.catalina.jsp_classpath";
public static final String SERVLET_CLASS_LOADER = "org.apache.catalina.classloader";
public static final String ATTRIB_JSP_ProtectionDomain = "tomcat.context.jsp.protection_domain";
org.apache.jasper.JasperLogger
The logger used to be initialized by the servlet container. We now
need to make it work standalone.
<p>
</pre>
<p>
<h3>Jasper published API</h3>
[From <a href="jasper-proposal.html">Proposal for Development of Jasper in Tomcat 4.0</a>]
<p>
It shall be feasible for servlet containers (such as Tomcat) to
support mechanisms for improved performance of the
generated servlets that depend on internal knowledge of the JSP
page compiler, the servlet classes that it generates,
and the runtime support classes, if it chooses to do
so. Therefore, key features and integration points of the
generated servlet classes and runtime support classes shall be
exposed through interfaces that can remain stable
across enhancements to the Jasper code base.
1.1 jakarta-tomcat-4.0/jasper/doc/dev/jasper-proposal.html
Index: jasper-proposal.html
===================================================================
<html>
<head>
<title>Proposal for Development of Jasper in Tomcat 4.0</title>
</head>
<body bgcolor="white">
<div align="center">
<h1>Proposal for Development of Jasper in Tomcat 4.0</h1>
<h2>$Id: jasper-proposal.html,v 1.1 2000/08/30 20:09:35 pierred Exp $</h2>
</div>
<h2>Introduction</h2>
<p>The specification for JavaServer Pages<sup>TM</sup> (JSP) version 1.2 is
likely to require, among other things, exposing the internal structure of a
JSP page to custom tag libraries at page translation time. This will require
some substantial changes to the existing Jasper code base, and offers us the
opportunity to improve its internal organization and functionality.
Prior to undertaking these efforts, it is appropriate for us to discuss
and agree on the high level goals we wish to achieve, and the proposed overall
architecture of the new code.</p>
<p>This document proposes a set of goal statements, along with related
assumptions and implications, for the purpose of gaining consensus and
agreement at a high level. It also includes a first cut at an overall
architecture (subject to change if the goals change during the process of
consensus building)</p>
<p>Jasper is, and is proposed to remain, the component of Tomcat that compiles
and executes JSP pages. If the proposal on source code organization is also
accepted, it will live in a "jasper" subdirectory of the new
<code>jakarta-tomcat-4.0</code> CVS module.</p>
<h2>High Level Goals for Next Generation Jasper</h2>
<p>The statements in the following sections describe goals by which we can
measure the completeness and success of the efforts to develop the next
major version of the JSP page compiler and runtime environment currently known
as Jasper.</p>
<h3>Specification Compliance</h3>
<p>The result of this coding effort will support 100% of the required
functionality described in the JSP 1.2 specification (to be available as
an initial public draft fairly soon), as well as the relevant portions of
the Servlet 2.3 specification (to be available at the same time).</p>
<ul>
<li>The means by which specification conformance is tested shall include
passing 100% of the JSP tests in the <strong>jakarta-watchdog</strong> test
suite, as it is evolved to include tests for all the new features.</li>
<li>The servlet and JSP API classes against which Jasper is compiled and
executed shall be the most current version of the API classes for
JSP 1.2 and Servlet 2.3 that have been checked in to the
<strong>jakarta-servletapi</strong> repository while these specifications
are in public review. After the specifications are final, the final
versions of the API classes, as amended for any formally adopted errata
on the specifications after the are final, will be utilized.</li>
<li>In addition, Jasper shall provide a web application containing unit tests
to validate the functionality of its own behavior, above and beyond the
specification requirements.</li>
</ul>
<h3>Compiler Environment and Requirements</h3>
<p>The JSP page compiler component of Jasper shall operate in the following
environments:</p>
<ul>
<li>It shall be possible to execute the JSP page compiler, and produce the
corresponding servlet classes representing these pages, from a command
line application (currently <code>jspc</code>), without having to be
executed within a servlet container.</li>
<li>It shall be possible to embed the JSP page compiler as a servlet in any
servlet container conforming to the Servlet 2.3 Specification (not just
Tomcat). Among other things, this implies that there shall be no internal
code dependencies within Jasper on any classes in the
<code>org.apache.tomcat.*</code> package hierarcy.</li>
<li>When embedded as a servlet, the JSP page compiler shall support both
on-demand page compilation (when it detects that the source code of a
page has been changed) or on-request page compilation (based on the
reserved precompilation request URIs described in the JSP 1.2
specification).</li>
<li>When embedded as a servlet, the JSP page compiler shall support
optional compilation of JSP pages in the entire web application, or within
designated portions of the context-relative URI space, in response to
an "application startup" event.</li>
<li>It shall be feasible for servlet containers (such as Tomcat) to support
mechanisms for improved performance of the JSP page compiler that depend
on internal knowledge of the JSP page compiler and its classes if it
chooses to do so. Therefore, the key features and integration points
of the JSP page compiler shall be exposed through interfaces that can
remain stable across enhancements to the Jasper code base.</li>
<li>It shall be possible to embed the JSP page compiler inside a development
tool in such a way that JSP pages can be translated on request from within
that tool.</li>
</ul>
<p>The JSP page compiler component of Jasper shall support the following
high level functional capabilities:</p>
<ul>
<li>The compiler shall accept input pages in either the JSP syntax or the
XML syntax, as described by the JSP 1.2 Specification.</li>
<li>It shall be possible to use the appropriate portions of the compiler
(principally the parser) to build a tool that translates a page in
JSP syntax into a corresponding page using the XML syntax.</li>
<li>When executed in a stand-alone environment, or from within a development
tool, the JSP page compiler shall include the optional ability to generate
elements to be included in the web application deployment descriptor
(<code>WEB-INF/web.xml</code>) of the web application in which these
servlets will be included.</li>
<li>When executed from within a servlet container, the JSP page compiler
shall support the option to retain intermediate versions of the translated
source code (such as the internal XML representation and the Java source
code representation) after translation is complete.</li>
<li>The JSP page compiler shall support configurable properties and plugins
for customizing its functionality, including (but not limited to):
<ul>
<li>The mechanism by which Java class names for the generated servlet
are created.</li>
<li>The package name into which generated servlets are placed.</li>
<li>The processing performed for scriptlets, so that languages other than
Java can be used. The standard Jasper page compiler shall support
Java language scriptlets.</li>
<li>The Java compiler to be used for translating Java source code into
the corresponding servlet class file.</li>
</ul>
</li>
<li>The JSP page compiler shall support the optional generation of debugging
information (such as line and column numbers) that will assist the runtime
environment in identifying error locations in the original JSP page.
Initially, this debugging information shall be similar to that generated
by Jasper in Tomcat 3.2; however, once the JSR-045 specification (related
to adding debugging information to Java class files for non-Java languages)
is available in public draft, it shall be possible to configure the
generation of debugging information in this format as well.</li>
<li>The JSP page compiler shall support the ability to generate servlets
that extend a developer-provided superclass (rather than the default one
available in the runtime support classes included with Jasper), as
required by the JSP 1.2 specification. However, the organization of the
generated servlet code, and associated runtime support classes, should be
optimized for the case where the default superclass will be utilized.</li>
<li>To the maximum degree feasible, translation errors shall be reported
in terms of line and column numbers from the original JSP source page,
rather than line numbers in the generated servlet.</li>
<li>The JSP page compiler shall generate servlets that conform to all of the
requirements described below in section "Runtime Environment and
Requirements."</li>
</ul>
<h3>Runtime Environment and Requirements</h3>
<p>The servlet classes produced by the JSP page compiler (no matter which
mode the compiler itself was executed in) shall operate in the following
environments:</p>
<ul>
<li>The generated servlet classes may depend on runtime support classes that
are specific to Jasper. These runtime support classes shall be available
in a JAR file that can be included in the <code>WEB-INF/lib</code>
directory of a web application in which the generated servlet classes
will be executed, or made available as server extensions by whatever means
are supported by the servlet container they are deployed into.
<li>It shall be possible to deploy the generated servlet classes, and the
associated runtime support classes described above, on any servlet
container conforming to the Servlet 2.3 Specification (not just Tomcat).
Among other things, this implies that there shall be no internal code
dependencies in the generated servlet classes, or the runtime support
classes, on any classes in the <code>org.apache.tomcat.*</code>
package hierarchy.</li>
<li>It shall be feasible for servlet containers (such as Tomcat) to support
mechanisms for improved performance of the generated servlets that depend
on internal knowledge of the JSP page compiler, the servlet classes that
it generates, and the runtime support classes, if it chooses to do so.
Therefore, key features and integration points of the generated servlet
classes and runtime support classes shall be exposed through interfaces
that can remain stable across enhancements to the Jasper code base.</li>
<li>The generated servlet classes shall have no runtime dependencies on any
classes in the JSP page compiler. It shall be possible to run them in
a web application where all JSP pages have been precompiled, and no
runtime JSP page compilation is available. It shall also be possible
to run them (and recompile them if necessary) in an environment where
runtime JSP page compilation is available.</li>
<li>The generated servlet classes shall operate under the class loader and
security domain (if any) established by the servlet container in which
they are deployed.</li>
</ul>
<p>The servlet classes produced by the JSP page compiler (no what what
environment it was executed in) shall support the following high level
functional capabilities:</p>
<ul>
<li>To the maximum degree feasible, runtime exceptions shall be reported
in terms of line and column numbers from the original JSP source page,
rather than line numbers in the generated servlet.</li>
<li>Stack traces produced in response to translation or runtime errors may
be logged (via <code>ServletContext.log()</code>), but shall not be
reported back to clients whose requests triggered the errors.</li>
</ul>
<h2>Overall Architecture Proposal</h2>
<p>The following diagram contains the first cut at an overall architecture
for the next generation Jasper compiler, taking into account the goals
described earlier.</p>
<p><strong>FIXME - image containing the architecture diagram</strong></p>
<p>As you can see, the compiler is divided into several phases, with the
functionality described below:</p>
<ul>
<li><strong>Parser</strong> - Accept as input a page in either JSP syntax or
XML syntax, as described by the specification. Produce as output a DOM
view of the underlying page, as well as related source file debugging
information that can be passed along to be included in the servlet class
that is ultimately generated.</li>
<li><strong>Transformer</strong> - Accept as input the DOM and debugging
information provided by the Parser, and support the translation time
transformations described in the JSP 1.2 specification. The output will
be a revised DOM tree (transformed in place?) and revised debugging
information.</li>
<li><strong>Generator</strong> - Accept as input the (possibly transformed
and validated) DOM and debugging information from the Transformer, and
generate the source code for a Java servlet that implements the desired
functionality of the JSP page.</li>
<li><strong>Translator</strong> - Accept as input the Java servlet produced
by the Generator, and compile it with the configured Java compiler to
produce a servlet class file for this page.</li>
<li><strong>Deployer</strong> - If this page is being compiled in a stand
alone environment, the Deployer phase can be invoked to produce the
appropriate additions to the web application deployment descriptor
(<code>web.xml</code>), and a JAR file containing the compiled page
classes, to be included in a web application.</li>
</ul>
<p>The following points should be kept in mind when considering how to
implement the phases described above:</p>
<ul>
<li>At first blush, it would appear that the Parser could use a standard
JAXP-compatible DOM parser (with validation enabled) when reading XML
input. However, this will not be feasible for the following reasons:
<ul>
<li>Any JSP page (in XML syntax) that uses custom tag libraries will
not be possible to validate, because the custom tag attributes
themselves are not available in the DTD of the JSP page itself.</li>
<li>If you use a non-validating DOM parser, there is no access to source
line and column number information.
</ul>
Therefore, it appears that we should implement two parser front ends
(one for each syntax) that generate SAX events, and build a common parser
back end that produces the DOM and debugging information to be handed on
to the Transformer.</li>
<li>The front end for JSP syntax can be based on the existing parser code in
Jasper, after modifying to produce output in the expected format.</li>
<li>It should be easy to add a command-line tool that takes the DOM as input
and produces a page source file (in XML syntax) as output. This would be
useful for developers who wish to switch from JSP syntax to XML syntax
without having to manually recode all of their pages.</li>
<li>The Transformer phase will also likely support the concept of validators
that examine the DOM of the page for consistency with application
standards. Therefore, it can also cause fatal translation time errors.
</li>
<li>Since we are not using a validating XML parser for the reasons described
above, we should consider using an internal validator at this stage to
check for "validity" of the DOM in the XML sense (proper nesting of
elements, no unknown attributes, and so on).</li>
<li>The Generator should be able to produce debugging information that is
similar to that produced by the current version of Jasper, for backwards
compatibility. In addition, it should track with the published results
of JSR 45, under which original line number information for any language
being translated into Java will be optionally included in the class file
itself.</li>
<li>At a minimum, the Translator phase should support Jikes and the built in
Java compiler from the JDK (as is supported by the current version of
Jasper). To the maximum degree feasible, we should also support plug in
of different Java compilers through some appropriate interface.</li>
<li>Deployer support is something that can be done in a minimal fashion early
on (similar to what <code>jspc</code> does now), but I envision enhanced
capabilities in this area being added later.</li>
</ul>
<p>Although it is too early for detailed source code design, I would suggest
that the source modules for each phase of the JSP page compiler be organized
into a separate Java package (such as <code>org.apache.jasper.generator</code>
for the Java code generation phase). Interfaces that describe cross-phase
information flows can be defined in the <code>org.apache.jasper</code>
package, with implementations provided by the phase that actually produces
that information.</p>
<p>In a similar manner, the runtime support classes that a generated page
may depend on should be organized into a single Java package (such as
<code>org.apache.jasper.runtime</code>), to facilitate easy packaging as a
JAR file, and to discourage dependencies on other Jasper internals.</p>
</body>
</html>
1.1 jakarta-tomcat-4.0/jasper/doc/dev/status.html
Index: status.html
===================================================================
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<title>Jasper -- README</title>
</head>
<body>
<h1>Status of Jasper</h1>
The goal of this document is to keep everyone informed of the major developments
happening with Jasper.<br>
<i>$Id: status.html,v 1.1 2000/08/30 20:09:35 pierred Exp $</i>
<h2>Current Status</h2>
Trying to bootstrap the work required to bring Jasper in compliance
with the new JSP 1.2 spec (according to the guidelines proposed by Craig
in a previous posting).
<p>
Interested developers, please have a look at the <a href="TODO.html">TODO</a> document, provide feedback.... and volunteer!.
<h2>History</h2>
<ul>
<li>2000/09/02
<br>In an effort to bootstrap the work required to bring Jasper in compliance
with the new JSP 1.2 spec (according to the guidelines proposed by Craig
in a previous posting), new developer documentation was committed to the
workspace to help us all be in sync with the current efforts, and what
needs to be done. Check the <a href="README.html">README</a>.<p>
<li>2000/08/25<br>
One of the goals of the new architecture of Jasper is to be independent of the servlet engine. This is why jasper now stands in its own directory in tomcat-4.0. It currently works with Catalina, with only a few dependencies, which we will work on removing. Please check the document <a href="jasper-independent.html">Jasper as an Independent Component</a> for the story.