I have made some changes to the Jasper code in Tomcat 4 that
you might want to look at.
1. In general the Java SecurityManager implemenation in Tomcat 4
and Jasper has significant improvements and is much cleaner.
2. Jasper class loading is much simpler in the Tomcat 4 version.
It uses a single URLClassLoader for each JSP page, this allowed
me to simplify a great deal how Jasper handles generation of class
and package names (no more need to do incremental .java and .class files).
And it removed alot of overhead at both JSP translation and runtime
when Jasper tries to figure out which incremental class file to use/check.
This sped up JSP compiles by 33% and runtime execution by 25%.
And before you ask, I just don't have the time to back port these
changes in TC3.3.
Regards,
Glenn
Mel Martinez wrote:
>
> 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/
--
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
