> 1. In general the Java SecurityManager implemenation in Tomcat 4
> and Jasper has significant improvements and is much cleaner.
True. The SecurityManager in 3.3 is working fine for now ( Glenn is also
the main author for the 3.x sandboxing ), with all watchdog passing - but
a refactoring will help cleaning up the code.
> 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%.
Well, I have to disagree here :-) It is indeed much simpler than the 3.2
jsp class loading, and using URLClassLoader is a step in the right
direction.
Tomcat 3.3 is also using URLClassLoader ( for everything - except the
JDK1.1 replacement that has the same interface and replicates
URLClassLoader ).
I would say the incremental .java is not a bad idea, and the code to
support that is reasonably simple ( and provide some unique benefits
related with reloading and avoiding some special cases ) - it should be
trivial to make it optional ( if anyone feel the need ).
We don't use a class loader per jsp page ( since it isn't needed - given
the versioning ), but again it would be easy to add it.
In any case - at least the class loading is just fine in 3.3, no need to
fix it ( but I think everyone would be happy to have more options - like
what you mention about one class loader per jsp and no versioning - as
long as this is not mandatory and doesn't replace the other scheme ).
> And before you ask, I just don't have the time to back port these
> changes in TC3.3.
Well, it would help a lot if you could at least take a look and review the
sandboxing for 3.3 :-) Security and sandboxing are very difficult, and you
probably have the most experience with that.
On a related issue, I would be very interested in re-commiting some of the
original patches ( defining the permissions in server.xml in addition to
the policy file ), this would help a lot in the future admin
interface. Again, we might need your help ( if you still have them
around ) :-)
Costin
>
> 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/
>
>
