I have done some work in this area that may be of
interest. I've created a package of 8 classes that
extend the Jasper compiler (as of Tomca 3.2.1) to
provide:
- dynamic recompiling/reloading of jsp pages
- recursive detection of changes to static includes
- support for inner classes
- customizable name mangling (giving finer control
over the package and class names of .java and
.class files generated
- configurable top-level package name
and a few other features. The result seems fairly
robust and not dependent on the any particular servlet
engine (I'm running it as a servlet to replace the jsp
compiler in WebLogic Server which has some design
problems that interfere with my project goals).
I achieved these features by simply extending the
existing API as of v 3.2.1, although from what I can
tell, there should be no problem using tomcat 4.0 as
well.
Motivation for doing it this way instead of rewriting
the jasper classes directly and submitting changes to
the project is chiefly time-constraints. I needed the
features for my own projects and I did not have time
to go through becoming more properly involved. My
reasoning was that at this point, I could count on
certain aspects of the API that are common to both
v3.2.1 and v4.0 to be fixed so it was safest and
quickest to simply extend from there without having to
risk conflicts with any internal changes other folks
might be making.
The total amount of code is small, only about 17k
lines across the 8 files in the package which are :
package com.g1440.naf.j2ee.jsp;
JspBase - extends HttpServlet implements HttpJspPage
JspCompiler - extends Compiler implements Mangler
JspConstants - extends Constants
JspContext - extends JspEngineContext
JspLoader - extends JasperLoader
JspOptions *
JspPageHandler - replaces JspServletWrapper
JspServlet - extends JspServlet
* - original intention was for JspOptions to extend
EmbeddedServletOptions but for some reason that class
is final. Not a major problem in reality.
The result needs to have some proprietary code (mostly
debug and configuration related) removed and perhaps
given a package rename to be generally useable. I'm
open to suggestions on how best to manage this.
The key point for my own self-interest here (and why
I'm piping up with this at this point) are that no
changes should occur to the existing Jasper API that
would conflict with this extension. Other than that,
the above does not have to be 'merged' with Jasper's
current codebase but could continue to exist as a
separate entity. However, I would like others to
share in the benefits. The code quality is good, with
extensive javadocs. Some effort would need to be put
into repackaging to pull it out of my current project,
so I can't turn it all over on a dime (I'm pretty
freakin' busy these days), but it was written with
that eventual goal in mind. If it is just considered
a distraction, I can disappear quietly back into the
darkness... :-)
While I've got your attention, btw, I'd like to toss a
design question out there:
Currently, the java code generated by the JSP compiler
places the scriptlet code inside _jspService() inside
a try{...}catch(Exception... block. The catch passes
the caught Exception to the page context
handlePageException() method.
Although I believe this is within the JSP spec, I kind
of object to indescriminant blockage of the Exception
class like this. It interferes with one's ability to
use custom RuntimeExceptions that one needs to
communicate up to a parent HttpJspPage base class.
I would like some mechanism to override the page
catch() block to not process certain exception classes
and simply toss them up like they were meant to be.
This could be handled by a configuration property that
lists the Exception types to ignore or some other
configurable mechanism. I suppose one can override
the handlePageException() but this does not seem
optimal.
Looking forward to feedback,
Dr. Mel Martinez
Software Architect
G1440, Inc.
[EMAIL PROTECTED]
--- "Craig R. McClanahan"
<[EMAIL PROTECTED]> wrote:
> Glenn Nielsen wrote:
>
> > In order to make it easier to integrate the
> SecurityManager into Jasper
> > for Tomcat 4 and to change some of Japsers
> annoying behaviours, I have
> > been working on switching Jasper over to the
> URLClassLoader.
> >
> > I have the class loading changes in place and
> Jasper passes all watchdog
> > tests. I wanted to run these changes past
> everyone before I finish
> > cleaning up the changes and committing it. (I
> still have some work to
> > do on JspC and still need to add support for the
> SecurityManager.)
> >
> > Jasper now creates a URLClassLoader for each JSP
> page and defers any other
> > class loading to the web app context class loader.
> Using a single class
> > loader per JSP allowed me to remove all the code
> that increments the
> > class version number, i.e. the work directory no
> longer has multiple
> > *.java and *.class files for the same JSP page.
> These changes also made
> > it easy for me to put the java source and class
> files in the same directory
> > tree as found in the web app context. When Jasper
> is run in a servlet
> > container it no longer puts the class files in a
> package, they are now
> > in the default package.
> >
>
> I'm a little uncomfortable with making Jasper's
> servlets not belong to a package
> any longer. My issue relates to developers who
> (mistakenly) try to reference
> beans in <jsp:useBean> that are not in any package
> -- currently, that does not
> work in Tomcat, or in any other container that uses
> an implicit package. But,
> with this change, such an incorrect bean usage would
> work in Tomcat, but would
> cause portability problems for apps that depend on
> that behavior.
>
> I'd much rather see the generated servlets that
> Jasper creates continue to be
> placed in a package, to protect developers from
> themselves on this issue.
>
> >
> > These changes simplified the code quite a bit and
> also gave a performance
> > improvement.
> >
> > When running watchdog tests the new jasper was
> ~25% faster than the current
> > jasper on a first compile or on first jsp class
> access after restart.
> > On recompile of a jsp page it was 37% faster.
> Execution of JSP servlet
> > after it had already been compiled and loaded was
> slightly faster.
> >
>
> That's great!
>
> >
> > Regards,
> >
> > Glenn
> >
>
> Craig
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, email:
> [EMAIL PROTECTED]
>
__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
