As hinted at last week, I'd like to propose
refactoring some of the classes in Jasper to improve
the OO model a bit, make maintenance/extendability a
bit easier and hopefully help the performance a bit as
well for those of us using jasper as the JSP engine in
other servlet engines (other than tomcat, that is).
There are problems with using the current Jasper in
other ServletEngines that do not show up with the
tomcat JspIntercepter that need to be addressed.
I'd like to refactor JspServlet, JspServletWrapper,
JasperLoader, JasperEngineContext and JasperCompiler
to better divide responsibilities along the following
lines:
JspServlet - entry point for JSP page (*.jsp),
initialize Jasper and maintain cache of jsp servlet
wrapper/handlers, otherwise do very little but pass on
the request to the handler. I.E. represents the scope
of the jasper engine. Possibly rename this to
JasperServlet or just 'Jasper'.
JspServletWrapper - rename as 'JspServlet/PageHandler'
(or similar) and make this a full class (i.e. take it
out of JspServlet). This class manages the life cycle
of a single Jsp file, including methods to resolve
relevant file paths (i.e. to .jsp file, .java file,
.class file), package/class name mangling and
modification checking. This class would be
responsible for managing dynamic reloading of an
out-of-date page. Only one instance of this class is
created per page for the life JVM (or more accurately,
for the life of the JspServlet).
JspRequestWrapper/Handler/Context - encapsulate
information relevant to one request - this would
implement JspCompilationContext, since a compilation
would be one possible event during the request.
However, we'd remove some of the current behavior in
JasperEngineContext that is really page-lifecycle
behavior that belongs in the JspServlet/PageHandler.
This class should be a lightweight information
payload used by the page handler, loader and compiler
for fullfillment of the request. By reducing the
number of fields to only those that are
request-specific and possibly by object pooling, the
impact of instance creation (necessary for each
request) can be greatly reduced.
JasperLoader, Compiler, and a few other classes would
be refactored (actually simply extended slightly
through subclassing) to support these mods. Some of
the current behavior would be refactored out to the
page life-cycle handler. Compilers can probably be
pooled for reuse.
Along with the above class refactoring, we would add
recursive modification checking and dynamic reloading
to JspServlet, miscelaneous bug and performance fixes
(ex: mangled filename caching), and factory methods to
make it easier to modify behavior by pluging in
replacement classes (such as the name mangler, loader
and compiler). I'd like to improve the way classpaths
are handled to make things more apparent to the
developer using Jasper standalone how to set things
up.
The beauty of this is that this can all be done
without rewriting much if any of the existing code in
TC3.3. We can simply create a separate implementation
of JspServlet, called 'Jasper' (or JasperServlet or
whatever) or place the changes in a separate package
and thus folks working with the current version would
not be impacted by API changes. We can then deprecate
the current classes gradually.
It is imporant to note that this proposed refactoring
would be to the standalone JspServlet page and request
life-cycle management. This does not address any
possibly needed refactoring of the actual Jasper
compiler, which will remain the common element used by
all three entry points: JspInterceptor, the current
JspServlet and the proposed new jsp servlet.
Maintaining runtime compatibility with JspInterceptor
is, of course, mandatory. No changes should cause
JspInterceptor to break. Maintaining consistency with
JspInterceptor in terms of how it might do some
ancillary things (name mangling, caching
optimizations, classpath resolution etc.) should also
be desired, but not required since, after all,
JspInterceptor represents value-added for the tomcat
servlet engine.
To facilitate development, I can donate the bulk of
this as finished code I've already written that simply
needs to have appropriate package and class renaming
applied.
This proposal should be considered a rough draft. I
need feedback, especially from others also using
Jasper as standalone in other servlet engines (such as
WebLogic Server, JRun, Jserv, etc.) on what problems
they'd like to see solved. I'd also like suggestions
on whether to put this into a separate package in
Jasper (ex: org.apache.jasper.embedded) or to simply
insert it into the existing org.apache.jasper.servlet
package using new class names. I think I'm in favor
of the latter approach. I don't think there will be
much conflict or confusion with the approach I'd like
to take.
That said, I will have actually some time later this
week to actually implement most of this. So feedback
now is better than feedback later.
Cheers,
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
